2 min read
What triggers it
You exceeded the request rate. More than 60 requests per 60 seconds per IP on the public ring.
Example response
{
"error": {
"type": "rate_limit_error",
"code": "rate_limited",
"message": "You exceeded the request rate."
}
}
How to fix it
Back off until Retry-After elapses; batch or cache where you can.
This class is transient — see Retrying failed requests.
In practice
In a well-built client, rate_limited is handled by branching on error.code rather than on the human error.message, which may be reworded over time. The HTTP status (429) gives the broad rate_limit_error class; the code gives the specifics; and, on field errors, error.param pinpoints the input to fix.
This code is transient, so it belongs in the retry path: back off with jitter, honour Retry-After on a 429, and pair writes with an idempotency key so a retry after a timeout never double-applies. See Retrying failed requests and Build a resilient API client.
Frequently asked questions
Is rate_limited safe to retry?
Yes, with exponential backoff — it is transient.
Will this code ever change?
No. Error codes are stable contract. The human message may be reworded, but the code you branch on will not change.
Do I branch on the code or the HTTP status?
Both — the status for the retry-or-not decision, the code for the specific behaviour. See the error envelope.
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.