429 Too Many Requests
The client has sent too many requests in a given period and is being rate limited.
Status
HTTP/1.1 429 Too Many Requests
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 6585 §4
- Cacheable: Only with explicit cache headers
- Response body: Allowed
- Retry: Retry after a delay
429 is the polite form of a block. The server is telling you the rate is too high and, through Retry-After, roughly when to come back. Limits are usually applied per API key, per IP address, or per session, and often several limits apply at once.
Ignoring it escalates. Clients that keep hammering through 429s frequently graduate to a sticky 403 or an outright IP ban, which is far harder to recover from than waiting out a window.
Note: Honour Retry-After. Retrying earlier extends the penalty on most implementations, and sustained pressure often escalates a 429 into a sticky 403 or an IP ban.
Headers
- Retry-After: Seconds to wait, or an HTTP date. Honour it rather than guessing.
- RateLimit-Limit: Common non-standard header giving the quota for the window.
- RateLimit-Remaining: Requests left in the current window, useful for pacing before you hit the limit.
Common causes
- Request rate above the documented quota for a key, an account, or an address.
- Concurrency limits exceeded even when the total rate looks acceptable.
- Many clients sharing one outbound IP, so the limit is reached collectively.
- A retry storm from failed requests compounding the original rate.
How to fix it
As the client
- Honour Retry-After exactly. Retrying earlier extends the penalty on most implementations.
- Add exponential backoff with jitter so parallel workers do not resynchronize into a burst.
- Track RateLimit-Remaining and slow down before hitting zero rather than after.
- Spread traffic across more source addresses when the limit is per IP, and cache aggressively to cut request volume.
As the server
- Always send Retry-After. A 429 without it forces clients to guess and usually to guess badly.
- Publish the limit and window in headers so well-behaved clients can pace themselves.
- Rate limit per credential rather than per IP where possible, so shared networks are not penalized collectively.
Examples
Hitting a rate limit
A request that crosses the rate limit for its API key:
HTTP request
GET /api/v2/order HTTP/1.1 Host: api.example.com Authorization: Bearer sk_live_example
Retry-After says how long to wait. Retrying earlier usually extends the penalty:
HTTP response
HTTP/1.1 429 Too Many Requests Retry-After: 30 RateLimit-Limit: 600 RateLimit-Remaining: 0
Notes for proxy users
When a rate limit is applied per IP, concurrency is bounded by how many distinct addresses you have. Splitting a crawl across a pool of static residential ISP addresses keeps each address under the threshold, while a single address running the same total volume collects 429s and then blocks. Pacing per address matters more than raw pool size.