429 Too Many Requests: Rate Limiting in Action
Retry-After header indicating how long the client should wait before making a new request. Clients should implement exponential backoff and respect the Retry-After value.
How Rate Limiting Works
Rate limiting restricts the number of requests a client can make within a specific time window (e.g., 100 requests per minute). When the limit is exceeded, the server returns 429 Too Many Requests. The server may also send a Retry-After header with a number of seconds or a date/time after which the client can retry.
Common Causes of 429 Errors
| Cause | Example | How to Fix |
|---|---|---|
| High request frequency | Client sends 200 requests in 1 minute when limit is 100/min. | Reduce request rate; implement caching or batch requests. |
| Multiple clients from same IP | Many users behind a corporate proxy sharing the same IP. | Use API keys to distinguish clients; increase IP-based limits. |
| Bursty traffic | Client sends many requests in a short burst (e.g., scraping). | Use exponential backoff or spread requests over time. |
| Server policy | Server intentionally limits free tier users. | Upgrade to a higher tier or wait for the limit to reset. |
Example: 429 Response with Retry-After
A client exceeds the rate limit and the server responds:
How to Fix 429 Errors
- If you're a client developer: Implement exponential backoff (e.g., wait 1s, 2s, 4s, etc.) and respect the
Retry-Afterheader. Cache responses when possible to reduce the number of requests. Use batch endpoints if available. - If you're a server administrator: Adjust rate limiting settings (e.g., increase the limit, extend the time window, or use a sliding window algorithm). Use API keys to differentiate clients behind the same IP.
- If you're an end‑user: This error usually indicates heavy usage of an API. Wait a few minutes and try again, or contact the service provider to increase your limits.
Rate Limiting Algorithms
- Fixed Window – counts requests in a fixed time window (e.g., 100 requests per minute).
- Sliding Window – more precise, counts requests in a moving time window.
- Token Bucket – allows bursts but limits average rate.
- Leaky Bucket – smooths out bursts, processes requests at a constant rate.
Frequently Asked Questions
Is 429 a client error or a server error?
It's a client error (4xx) because the client is sending too many requests. The server is working correctly but is enforcing a rate limit to protect itself.
What is the Retry-After header?
The Retry-After header tells the client how long to wait before making a new request. It can be an integer (seconds) or an HTTP date. Clients should respect this value to avoid being blocked further.
Can I get a 429 even if I'm not making many requests?
Yes, if your IP is shared with other users (e.g., corporate proxy, VPN), the aggregate request count may exceed the limit. Use an API key to get a separate limit.