The 429 Too Many Requests error has become a rite of passage for anyone building against a third-party API. You write the integration, it works in testing, you ship it, and then at some point production traffic hits and the API starts spitting 429s. Understanding what's actually happening — and how to stop it — takes about five minutes and saves hours of debugging later.
What "rate limit" means in practice
Rate limits are quotas: most commonly a count of requests allowed in a rolling time window. The format varies — "300 requests per 15 minutes," "5,000 per hour," "100 per second" — but the pattern is always N requests per T time. Once you've hit the limit, further requests fail with 429 until enough time has passed for the window to roll over.
Some APIs use sliding windows (your quota is counted over the last T seconds at all times) and some use fixed windows (quotas reset at the top of the minute/hour/day). The difference matters: with a fixed-window API, you can legally fire all 300 requests in the first second of the window, then make zero requests for the remaining 14 minutes, and technically not get rate-limited — but the burst behavior tends to create other problems at the server end.
Reading the response headers
The 429 response usually tells you exactly what went wrong and what to do next. The standard headers (many APIs also support X-RateLimit-* variants):
| Header | Meaning |
| --- | --- |
| RateLimit-Limit | Your total quota for the window |
| RateLimit-Remaining | Requests left in the current window |
| RateLimit-Reset | Unix timestamp (or seconds) until the window resets |
| Retry-After | Seconds to wait before retrying (sometimes on 503 too) |
Read RateLimit-Remaining before you hit 0, not after. If you're building a bulk operation against a 429-prone API, check the remaining count after each request and pause proactively when it drops below your minimum safe buffer.
Pacing: the math that prevents 429s
If your limit is N requests per T seconds, the safe per-request interval is simply T / N. For 300 requests per 15 minutes (900 seconds), that's 900 / 300 = 3 seconds per request — one request every 3 seconds guarantees you never exceed the limit, regardless of when in the window you start.
When you have multiple parallel workers sharing a limit, the math extends: with K workers sharing a N/T quota, each worker should wait T / (N / K) = K × T / N between requests. Two workers under the same 300/15min limit should each pace at 6 seconds.
The third question — "what if I have a daily quota too?" — means converting: N requests per 24 hours / 86,400 seconds = max rate per second. If the daily quota is more restrictive than the per-minute limit, you need to pace to the daily rate even when the per-minute window would allow faster bursting.
Backoff that doesn't make things worse
The most common mistake after getting a 429 is to retry immediately — which often produces another 429, then another, in a tight loop that exhausts whatever time-based grace the API still gives you. The alternatives:
Respect Retry-After first. If the response includes it, that's the minimum wait. Don't guess; use it.
Exponential backoff with jitter. When there's no Retry-After, start with a base wait (e.g., 1 second), double it on each retry, and add a small random jitter (say ±20%). Jitter is critical: without it, multiple clients that all hit the limit at the same time all retry at the same time, creating a synchronized thundering herd that hits the API in waves. Jitter desynchronizes them.
wait = min(base × 2^attempt, cap) + random(0, jitter_max)
Cap your maximum wait. Exponential backoff without a ceiling eventually waits for hours. Decide on a maximum (30–60 seconds is typical for interactive API calls; longer for batch jobs) and stop doubling there.
Track 429s distinctly from 5xx errors. A 429 is a quota issue; a 500 or 503 is a server error. They warrant different retry strategies — a 503 with Retry-After is telling you the server is overloaded, not that you've exceeded a quota.
Calculate your safe rate
Our Rate Limit Calculator takes any N requests per T time quota and tells you: the safe per-request interval for a single client, how to split that budget across parallel workers, and what rate you need to stay under for a given daily quota — so you can set the right sleep() values in your code before you ever hit a 429, not after.