Quick answer
HTTP 429 Too Many Requests means the client has sent too many requests in a given time and hit a rate limit. Check the Retry-After header and back off before retrying.
What HTTP 429 means
429 Too Many Requests is returned when a client exceeds a rate limit. The response often includes a Retry-After header indicating how long to wait, and sometimes X-RateLimit-* headers describing the limit and remaining quota. Well-behaved clients back off rather than retrying immediately.
"429 Client Error: Too Many Requests for url:" — the requests error
Calling an API from Python, this surfaces as an HTTPError when you call raise_for_status():
import requests
response = requests.get("https://api.example.com/data")
response.raise_for_status()
# requests.exceptions.HTTPError:
# 429 Client Error: Too Many Requests for url: https://api.example.com/dataA 429 means you have sent too many requests in a time window. Read the Retry-After response header (seconds or an HTTP date) and wait that long before retrying; add client-side throttling or exponential backoff to stay under the rate limit.
Common causes
- Sending requests faster than the API's rate limit allows
- A burst of traffic or a retry loop without backoff
- Sharing a rate-limited IP or API key across many clients
- Polling an endpoint too frequently
Example JSON error response
{
"error": "Too Many Requests",
"message": "Rate limit exceeded. Try again in 30 seconds.",
"status": 429,
"retry_after": 30
}Raw HTTP response
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0How to troubleshoot HTTP 429
- ✓ Check the API's documented rate limits
- ✓ Honor the
Retry-Afterheader before retrying - ✓ Implement exponential backoff with jitter on retries
- ✓ Review burst traffic and retry loops in your client
- ✓ Cache responses or batch requests to reduce call volume
Retrying a 429 the right way
Unlike a 400, a 429 is safe to retry — but only after waiting. Honor Retry-After if present (it's either a seconds count or an HTTP date); otherwise fall back to exponential backoff with jitter so many clients don't all retry at the same instant (the "thundering herd"):
async function fetchWithRetry(url, opts = {}, attempt = 0) {
const res = await fetch(url, opts);
if (res.status !== 429 || attempt >= 5) return res;
const header = res.headers.get('Retry-After');
const waitMs = header
? Number(header) * 1000 // server told us how long
: (2 ** attempt) * 1000 + Math.random() * 1000; // backoff + jitter
await new Promise(r => setTimeout(r, waitMs));
return fetchWithRetry(url, opts, attempt + 1);
}Rate-limit headers to read
Most APIs expose your current quota so you can throttle before hitting a 429:
| Header | Meaning |
|---|---|
Retry-After | How long to wait before retrying (seconds or a date) |
X-RateLimit-Limit | Max requests allowed in the current window |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | When the window resets (often a Unix timestamp) |
Watch X-RateLimit-Remaining and slow down as it approaches zero — proactively staying under the limit beats reacting to 429s.
Frequently Asked Questions
What does a 429 status code mean?
It means you have hit a rate limit — too many requests in too short a time. The server is asking you to slow down. The response usually includes a Retry-After header telling you how long to wait.
How do I fix a 429 error?
Respect the Retry-After header, implement exponential backoff with jitter, reduce how often you call the endpoint, and cache or batch requests. If you legitimately need a higher limit, contact the API provider.
What is the Retry-After header?
Retry-After tells the client how long to wait before making another request — either a number of seconds or an HTTP date. Honoring it is the correct way to recover from a 429 without making the problem worse.
Why add jitter to exponential backoff?
Without jitter, many clients that were rate-limited at the same moment will all retry at the same moment — a "thundering herd" that immediately triggers another 429. Adding a small random delay spreads the retries out so they don't synchronize and overwhelm the server again.
Is it safe to retry a 429 automatically?
Yes — unlike a 400, a 429 is transient, so retrying after a wait is correct. The key is to wait (honor Retry-After, or use exponential backoff with jitter) and cap the number of attempts. Retrying immediately or in a tight loop will just hit the limit again.
The server says your request was wrong
Most 4xx bodies carry a JSON error object explaining which field it objected to. Format it and read the detail — nothing leaves your browser.