429 Too Many Requests
The client has sent too many requests in a given time window and is being rate limited.
Defined in RFC 6585 §4
What 429 means
RFC 6585 defines 429 for rate limiting: the user has sent too many requests in a given amount of time. The response should include a Retry-After header, either a number of seconds or an HTTP date, telling the client exactly when it is safe to retry, and may include a body explaining the limit that was hit. Rate limiting exists to protect backend capacity, keep usage fair across tenants, and defend against abuse or an accidental request storm from a misbehaving client.
Beyond Retry-After, many APIs also expose machine-readable quota state through the IETF RateLimit header fields (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset) or vendor-specific equivalents such as GitHub's, Stripe's, or X's X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. These let a well-behaved client throttle itself proactively before ever hitting 429, and let dashboards or SDKs show developers how much quota remains in real time.
The correct client response to 429 is exponential backoff with jitter: wait an initial interval, roughly double it after each subsequent 429 up to a capped maximum, and add a random jitter component so that many clients retrying at once do not synchronize into a "thundering herd" that hits the server in lockstep. When Retry-After is present, it takes priority over a client's own backoff calculation, since the server has authoritative knowledge of when capacity will actually free up.
Rate limits are commonly enforced per IP address, which is simple but penalizes many users sharing one NAT'd or corporate IP, or per API key or access token, which is fairer because it ties the limit to an authenticated identity and its subscription tier; many systems combine both. CDNs and WAFs such as Cloudflare, AWS WAF, Fastly, and nginx's limit_req commonly enforce coarse-grained rate limiting at the network edge, using token-bucket or sliding-window algorithms, before traffic ever reaches the origin, while the application layer applies finer-grained per-user or per-endpoint quotas on top.
Common causes
- A client exceeds a fixed request quota, per minute or per hour, tied to its IP address, API key, or account tier.
- A retry loop with no backoff hammers the server again immediately after each 429, making the situation worse.
- A CDN- or WAF-level rate-limiting rule, such as a Cloudflare rate limit or an AWS WAF rate-based rule, trips on a burst of traffic.
- Multiple services or worker processes share one API key and collectively exceed its rate limit without coordinating between themselves.
- A scraping pattern, bot, or misconfigured cron job fires far more frequently than the documented limit allows.
- A sudden, legitimate traffic spike, such as a flash sale or a viral link, exceeds the capacity provisioned for that tenant.
How to fix a 429
If you are the client (browser user or API caller)
- Read and honor the Retry-After header, or RateLimit-Reset, before retrying, rather than retrying immediately.
- Implement exponential backoff with jitter for retries, capping the maximum wait interval so it does not grow unbounded.
- Track RateLimit-Remaining or X-RateLimit-Remaining and throttle proactively before actually hitting the limit.
- Use a token-bucket pattern inside the client SDK to smooth request bursts across multiple concurrent calls.
- Batch or cache requests to reduce overall call volume instead of polling an endpoint frequently.
If you run the server
- Always return a Retry-After header so clients know exactly when it is safe to retry.
- Publish RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers so well-behaved clients can self-throttle proactively.
- Choose per-IP versus per-API-key limiting deliberately based on how traffic is authenticated, and consider combining both.
- Offload high-volume rate limiting to a CDN or WAF (Cloudflare, AWS WAF, nginx limit_req) so abusive traffic is stopped at the edge before it consumes origin capacity.
- Use a token-bucket or sliding-window algorithm with a burst allowance rather than a hard fixed-window cutoff that unfairly penalizes traffic right at window boundaries.
Example
GET /api/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer sk_live_...
HTTP/1.1 429 Too Many Requests
Retry-After: 30
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30
Content-Type: application/json
{"error": "rate limit exceeded, retry after 30 seconds"}Try it live
Our free status responder returns a real HTTP 429 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/429