429 Too Many Requests 4xx

What does 429 mean?

A 429 Too Many Requests response means the client has sent more requests than the server is willing to process in a given time window — commonly known as rate limiting. The server isn't saying the request itself was wrong (that would be a 400), or that the client lacks permission (403) — it's saying "you're asking too fast, slow down."

429 was added later than most status codes — it comes from RFC 6585, published in 2012, specifically to give rate limiting a standard, machine-readable response rather than servers inventing their own conventions (some older APIs use 403 or even 503 for this, which is part of why rate-limit handling across different APIs can feel inconsistent).

How a 429 behaves

• It often includes a Retry-After header, telling the client how long to wait before trying again — either as a number of seconds or an HTTP date
• It's not cacheable — rate limit state is specific to the requester and changes over time
• Retrying immediately will almost certainly fail again — the entire point of the response is that the client needs to wait
• It can apply at different scopes — per API key, per IP address, per user account, or even per specific endpoint, depending on how the rate limiter is configured

Common causes

If you're building the API:

• A client (often a script or integration, sometimes a misbehaving retry loop) is making requests faster than your rate limit allows
• Your rate limiting middleware is correctly doing its job — 429 here is often a sign things are working as intended
• A bug causing accidental request loops — e.g., a webhook handler that re-triggers itself, or a frontend polling loop with no backoff

If you're calling an API:

• You're making requests faster than the documented rate limit allows
• Multiple processes/servers on your end are sharing the same API key without coordinating their combined request rate
• You're not respecting the Retry-After header or rate-limit headers (X-RateLimit-Remaining, etc.) that the API provides
• A retry loop without backoff is making the problem worse — each failed request triggers an immediate retry, which also gets rate limited, compounding the issue

If you're a website visitor:

• You're refreshing a page or submitting a form repeatedly in quick succession
• A browser extension or script on the page is making automated requests on your behalf
• Shared IP addresses (common office networks, VPNs) can cause one person's heavy usage to affect others on the same IP

How to fix it

As an API/website builder:

• Always include a Retry-After header on 429 responses — this is the single most useful thing you can do for API consumers
• Document your rate limits clearly (requests per minute/hour, and at what scope — per key, per IP, etc.)
• Consider returning rate-limit headers on every response (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset), not just on 429s, so clients can proactively avoid hitting the limit
• Differentiate between "hard" limits (429, must wait) and "soft" warnings if your system supports graceful degradation

As an API consumer:

• Implement exponential backoff with jitter — wait progressively longer between retries, with some randomness to avoid synchronized retry storms across multiple clients
• Respect the Retry-After header if present — it's the server telling you exactly how long to wait
• Batch or queue requests instead of firing them all at once, especially for bulk operations
• Cache responses where possible to reduce the total number of requests needed

As a website visitor:

• Wait a bit before refreshing or resubmitting
• Avoid rapid repeated clicks on submit buttons — most well-built forms disable the button after one click, but not all do
• If on a shared network and this happens often, the rate limit may be tied to your IP rather than your individual usage

429 vs related codes

Real-world examples

GitHub's API uses a combination of rate-limit headers on every response (so clients can monitor their usage proactively) and a 429-equivalent (historically 403 for some endpoints, increasingly 429 for newer ones) when limits are exceeded — a good illustration of how rate-limiting conventions have evolved over time even within a single provider. Twitter/X's API is famously strict about rate limits and is one of the most commonly cited real-world examples of 429 responses in developer discussions, often requiring careful request batching and caching strategies to work within.

SEO implications

If search engine crawlers receive 429 responses while crawling a site, they typically slow down their crawl rate automatically — most major crawlers respect rate limiting and will back off rather than hammering a site that's signaling it's overwhelmed. However, persistent 429s can mean fewer pages get crawled and indexed in a given timeframe, which can delay how quickly new or updated content shows up in search results. If you're running a site behind aggressive rate limiting (including via Cloudflare rules), it's worth checking that legitimate search engine crawlers aren't being caught by limits intended for abusive bots.

FAQ

What does "Retry-After" mean on a 429 response?

It's a header telling the client how long to wait before making the same request again — either a number of seconds (Retry-After: 30) or a specific date/time. Well-behaved clients should respect this value rather than retrying immediately.

Is 429 the client's fault or the server's fault?

Neither, exactly — it's more of a negotiation. The server has a capacity limit it's enforcing, and the client exceeded it. Unlike a 400 (client made a mistake) or a 500 (server made a mistake), a 429 often means both sides are working correctly, but the client needs to adjust its pace.

Why am I getting rate limited even though I'm not making that many requests?

If you're on a shared IP address (office network, VPN, shared hosting), the rate limit may be counting everyone's combined requests from that IP, not just yours. Some APIs also count requests across all API keys belonging to the same account.

What's the difference between 429 and 503?

429 is specifically about this client sending requests too quickly — it's a per-client signal. 503 is a general "the server can't handle requests right now" signal that applies to everyone, regardless of how many requests any individual client has sent.

Should I keep retrying until a 429 goes away?

Not without backoff. Retrying immediately and repeatedly will likely extend the rate-limit window or get your client flagged more aggressively. Exponential backoff (waiting progressively longer between attempts) is the standard, well-behaved approach.

Fun fact

429 is one of the newest "core" status codes in common use — it didn't exist in the original HTTP specifications and was only formally standardized in 2012, decades after codes like 404 and 500. Before that, APIs used a patchwork of 403, 503, and custom codes for rate limiting, which is part of why some older or less-updated APIs still don't use 429 consistently today.