API reference

Error code: rate_limited

rate_limited returns HTTP 429 with type: rate_limit_error. You exceeded the request rate. Branch on this code — it is stable — and apply the fix below.

2 min read

429HTTP status
rate_limitederror.code
RetryHandling

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.