Rate limit
A cap on how many requests a client may make in a window, enforced by the server.
A rate limit protects a service from being overwhelmed by any single client. It is usually expressed per minute or per hour, sometimes with a separate concurrency cap. Exceeding it returns HTTP 429, normally with a Retry-After header. Real throughput is bounded by whichever limit binds first, which is often concurrency rather than the headline number.
Full guide:
HTTP 429 rate limits: how long to wait, and which limit is binding
— Honour Retry-After if the response carries one, and otherwise back off exponentially with jitter. A 429 means the request was understood and refused for pacing, so nothing was processed and the identical request is safe to retry once the wait has elapsed. Retrying immediately is the one response that reliably makes things worse.
Key facts
- HTTP 429 means the request was well-formed and refused for pacing, so it should be retried after waiting rather than corrected.
- A Retry-After header may be a number of seconds or an HTTP date, and honouring it is more reliable than computing your own backoff.
- Headline per-minute limits and concurrency limits bind independently: 60 requests per minute with 3 concurrent slots is not 60 fast requests.
- Rate limits are commonly applied per key rather than per IP, so distributing traffic across machines does not raise the ceiling.
Frequently asked questions
I am well under the limit but still getting 429s. Why?
Usually a second limit is binding — concurrency, tokens per minute, or a burst allowance measured over a shorter window than the one you are watching. Check whether the response names which limit was hit.
Does a 429 mean my request was rejected entirely?
Yes, it was not processed. That makes it safe to retry as-is, unlike a 500, where the request may have partly taken effect.
Machine-readable copy of this page:
/glossary/rate-limit.md