™2 min read
The window
The public ring uses a fixed-window counter keyed on your IP and the route. Up to 60 requests inside any 60-second slot succeed; the 61st returns 429. When the window rolls over, the counter resets and you can call again. Different route keys count separately, so heavy use of one endpoint does not exhaust another.
The internal ring (authenticated /internal/v1/*) is far more generous at 600 requests per 60 seconds per actor, but that ring is out of scope for public integrations.
Reading Retry-After
Every 429 carries a Retry-After header with the number of seconds until the window resets. Honour it exactly — wait that long, then retry. Do not hammer the endpoint in a tight loop; that only extends the window.
{
"error": {
"code": "rate_limited",
"message": "Too many requests. Retry after the window resets."
}
}The right retry pattern
On a 429, sleep for the Retry-After value (add a little jitter if you have many clients), then retry once. For everything else, use exponential back-off capped at a few attempts. Keep normal traffic well under 60/60 s and you will rarely see a 429 at all.
Frequently asked questions
What exactly is the public-ring limit?
60 requests per 60 seconds per IP, as a fixed window, per route key. Exceed it and further requests in that window return 429 with a Retry-After header.
Does a 429 mean my request was processed?
No. A 429 means the request was rejected before processing. Nothing was recorded; retry after the window resets.
How should I back off?
Honour Retry-After on 429s — wait that many seconds, then retry. Use capped exponential back-off for other transient errors. Add jitter if many clients might retry at once.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.