--- title: "What Does 429 Too Many Requests Mean?" url: https://apyhub.com/blog/what-does-429-too-many-requests-mean author: ApyHub published: 2026-09-09T08:23:42.75882Z --- # What Does 429 Too Many Requests Mean? # What Does 429 Too Many Requests Mean? **A 429 means you sent too many requests in too short a window, and the server is asking you to slow down.** Nothing is broken. Your credentials are fine, your request is valid, and the endpoint exists. You have simply exceeded a rate limit. The fix is almost always in how you retry. ## Read the Retry-After Header First A 429 response usually includes a `Retry-After` header, and it is the most useful thing in the response. RFC 9110 defines it as either a number of seconds or an HTTP date: http ``` HTTP/1.1 429 Too Many Requests Retry-After: 30 Content-Type: application/json {"error": "rate limit exceeded"} ``` That means wait 30 seconds. Not five, not immediately. The server has told you exactly when it will accept traffic again, and honouring it is both correct and faster than guessing. If there is no `Retry-After`, fall back to exponential backoff. ## Exponential Backoff, With Jitter The standard retry pattern, and the two parts both matter. **Exponential** means doubling the wait each attempt: 1 second, 2, 4, 8, 16. This gives a struggling server room to recover instead of hammering it. **Jitter** means adding randomness to each delay. Without it, every client that hit the limit at the same moment retries at the same moment, and you get a thundering herd that recreates the problem. A random offset spreads them out. A simple version: ``` delay = min(base * 2^attempt, max_delay) + random(0, 1000ms) ``` Cap the maximum delay and cap the number of attempts. Retrying forever turns a temporary rate limit into a permanent stuck job. ## Watch the Rate Limit Headers Most APIs tell you where you stand before you hit the limit: http ``` X-RateLimit-Limit: 100 X-RateLimit-Remaining: 3 X-RateLimit-Reset: 1757433600 ``` Reading these proactively is better than reacting to a 429. If remaining is low, slow down before the server has to tell you. Header names vary. Some APIs use `RateLimit-Limit` without the prefix, following the draft standard. Check the docs. ## Five Ways to Stop Hitting It 1. **Respect `Retry-After`.** It is the server telling you the answer. 2. **Add backoff with jitter.** Never retry immediately, and never retry in lockstep with other clients. 3. **Make retries idempotent.** If the request might have succeeded before the 429, retrying could duplicate it. Use an idempotency key for writes. 4. **Batch where the API allows it.** One request handling ten items beats ten requests. Many APIs offer batch endpoints specifically to reduce call volume, such as [batch VAT validation](https://apyhub.com/apyhub/service/validate-vat-batch) taking ten numbers per call. 5. **Cache what does not change.** A large share of rate limit problems are the same request repeated. If the answer is stable, store it. ## Rate Limiting Is Per What? Worth checking, because it changes the fix. **Per key** is most common. All your traffic shares one budget, so a batch job can starve your live application. **Per IP** catches you out behind a NAT or in a shared environment, where someone else's traffic counts against you. **Per endpoint** means an expensive endpoint has a tighter limit than a cheap one. **Per second versus per month** are different constraints. A per-second limit is about burst behaviour and is solved with queuing. A monthly quota is about volume and is solved with caching or a bigger plan. If you are getting 429s from a per-second limit while nowhere near your monthly quota, the problem is concurrency, not usage. ## A Worked Example A nightly job processes 5,000 records through an API with a limit of 10 requests per second. **What fails:** fire all 5,000 concurrently. You get a handful of successes and 4,900 rate-limit errors, then a retry storm makes it worse. **What works:** a queue with a concurrency limit of 8, leaving headroom. Exponential backoff with jitter on any 429. `Retry-After` honoured where present. The job takes about ten minutes and completes. Slower on paper, faster in practice, because nothing is being retried. ## FAQ ### What does HTTP 429 mean? You have sent more requests than the server's rate limit permits in a given window. The request itself was valid; there were simply too many of them. ### How long should I wait after a 429? If the response includes a `Retry-After` header, wait exactly that long. If it does not, use exponential backoff with jitter, doubling the delay each attempt with a random offset and a maximum cap. ### What is exponential backoff with jitter? Doubling the wait between retries, plus a small random offset. The doubling gives the server time to recover; the randomness stops every client retrying simultaneously and recreating the overload. ### Why do I get 429 errors when I am under my monthly quota? Because you are probably hitting a per-second rate limit rather than a volume quota. These are separate constraints. A per-second limit is about concurrency and is fixed by queuing, not by upgrading your plan. ### Is it safe to retry after a 429? Safe for idempotent requests such as GET, PUT and DELETE. For POST, retry only with an idempotency key or a way to confirm the original never applied, since a 429 can arrive after the work was already done. ### What is the difference between 429 and 503? A 429 means you specifically are sending too much. A 503 means the server is unavailable for everyone, usually from overload or maintenance. Both may carry `Retry-After`. ### Should my own API return 429? Yes, if you rate limit. Include a `Retry-After` header and rate limit headers showing remaining quota. A 429 without guidance forces clients to guess, and they usually guess badly. ## Related * [What Is an Idempotent Request?](https://apyhub.com/blog/what-is-an-idempotent-request) - why safe retries depend on the method * [405 Method Not Allowed](https://apyhub.com/blog/405-method-not-allowed) - a different 4xx with a different fix * [API Chaining in 2026](https://apyhub.com/blog/api-chaining-in-2026-combining-api-calls-into-workflows-agents-can-run) - rate limits across multi-step flows Source: [RFC 9110, section 10.2.3](https://www.rfc-editor.org/rfc/rfc9110.html) *** ## About ApyHub [ApyHub](https://apyhub.com/) is a curated API catalog for developers, teams and AI agents: [file conversion](https://apyhub.com/catalog/file-conversion), [data validation](https://apyhub.com/catalog/data-validation), [OCR and extraction](https://apyhub.com/catalog/artificial-intelligence) and more across 20 categories. One key covers all of it, every endpoint is [MCP-ready](https://apyhub.com/mcp) so AI agents can discover and call them directly, and every service page has a playground for testing before you build. EU-based and EU-hosted, which keeps data residency simple for teams with GDPR obligations. [**Browse the catalog**](https://apyhub.com/catalog) | [**Get a free API key**](https://apyhub.com/auth/signup) - no credit card required.