HTTP 429 Too Many Requests

Quick reference

What it means

Rate limiting is a deliberate server-side policy that restricts how many requests a client (identified by IP address, API key, user account, or session) can make within a time window. When the client exceeds the limit, the server returns 429 instead of processing the request.

The time window can be structured in several ways: fixed windows (e.g., 100 requests per minute, counter resets at :00), sliding windows (100 requests in any 60-second period), or token buckets (requests consume tokens that refill at a fixed rate). The implementation affects how a client should pace its requests, but from the client's perspective a 429 means the same thing regardless: stop and wait.

Rate limits exist for several reasons: protecting server resources from abuse, ensuring fair access across multiple clients, enforcing pricing tiers on paid APIs, and preventing scraping or credential-stuffing attacks. A 429 is not an error in the traditional sense — it is the server working exactly as intended.

429 vs user-level vs IP-level vs account-level rate limits

Rate limits can be scoped differently depending on the API. An IP-based limit affects all traffic from a given address — relevant for shared hosting or NAT environments where many users share an IP. An API key or account limit is per credential. Some APIs enforce both simultaneously: per-IP burst limits and per-account daily quotas. When you receive a 429, the response body or documentation should indicate which limit was hit.

The Retry-After header

RFC 6585 recommends including a Retry-After header with 429 responses to tell the client when it may safely retry. The header accepts two formats:

Delta seconds: Retry-After: 60 — wait 60 seconds from the time of the response before retrying.

HTTP-date: Retry-After: Wed, 13 Apr 2026 12:00:00 GMT — do not retry before this absolute timestamp.

Many APIs also include custom headers alongside Retry-After to provide richer rate limit state: X-RateLimit-Limit (the total limit), X-RateLimit-Remaining (how many requests remain in the current window), and X-RateLimit-Reset (epoch timestamp when the window resets). These are conventions, not RFC-defined, but they are widely adopted by major APIs (GitHub, Stripe, Twitter/X, etc.).

If the server does not include Retry-After, the client must determine wait time on its own. Exponential backoff is the standard approach.

Common causes of 429 errors

Client-side burst traffic from a bug or loop

A retry loop without backoff, a pagination bug that requests the same page repeatedly, or a webhook consumer processing the same event multiple times can all trigger 429s. These are typically easy to identify: the 429s appear suddenly and are concentrated on a single endpoint.

Shared API key across services

Multiple services or instances sharing the same API key pool their request counts against the same rate limit. If the combined traffic exceeds the limit, all services start seeing 429s even though none individually is abusing the API. Each service should have its own key, or request quotas should be distributed across keys.

Aggressive polling instead of webhooks

Polling an API endpoint repeatedly to check for state changes is a common anti-pattern. A 1-second polling interval against an API with a 60-requests-per-minute limit will hit the limit in 60 seconds. Use webhooks, long polling, or server-sent events where available.

Crawlers or bots hitting rate-limited endpoints

Automated scrapers, link checkers, SEO crawlers, and monitoring tools can inadvertently trigger rate limits. If you operate an API, consider whether your rate limit scope and Retry-After guidance is clear in your documentation so that legitimate automated clients can comply.

Missing request queuing in distributed systems

Multiple application instances making concurrent requests to a shared external API can collectively exceed the rate limit even when each individual instance is well-behaved. A centralized request queue or a distributed rate limiter (like Redis with sliding window counters) prevents this.

How to handle a 429 response

1. Read the Retry-After header. If present, wait exactly that long before retrying. Do not retry sooner.
2. If Retry-After is absent, use exponential backoff with jitter. Start with a short wait (1–2 seconds), double it on each subsequent 429 (2s, 4s, 8s, 16s…), and add a random jitter component (±20–50% of the wait time) to prevent synchronized retry storms from multiple clients.
3. Set a maximum retry count. After 3–5 retries, fail gracefully rather than retrying indefinitely. Surface the error to the user or operator.
4. Reduce your request rate proactively. Check for X-RateLimit-Remaining headers on successful responses and slow down as the remaining count approaches zero, rather than waiting for a 429.
5. Review your request patterns. A 429 is a signal to re-examine whether the request volume is necessary. Caching responses, batching requests, or using more efficient API patterns (GraphQL, bulk endpoints) may eliminate the need for high request rates.

429 vs 503 vs 408 vs 503 with Retry-After

See also: 429 vs 503 comparison · 425 vs 429 comparison

SEO and crawler implications

Googlebot respects rate limits. If a site consistently returns 429 to Googlebot, Google Search Console will show a reduction in crawl activity, and the crawl stats report will reflect the server errors. Google will reduce its crawl rate automatically when it detects 429 responses.

Sustained 429s against Googlebot can cause pages to be crawled infrequently or drop out of the index if Google cannot successfully fetch them during a recrawl. Unlike 500 (which Google treats as temporary), a pattern of 429s suggests to Google that the site does not want to be crawled at the rate Google prefers.

To avoid accidentally rate-limiting Googlebot, ensure your rate limiting logic excludes or gives high limits to verified search engine crawlers, or configure your CDN to allowlist known Google IP ranges. Avoid setting global IP-based rate limits that do not account for legitimate crawlers.

FAQ

What does HTTP 429 mean?

HTTP 429 Too Many Requests means the client has sent more requests than the server allows in a given time window. The request was valid — the server is refusing it because of volume, not because of an error in the request itself.

What should I do when I receive a 429?

Check for a Retry-After header. If present, wait the specified number of seconds before retrying. If absent, implement exponential backoff: wait increasing intervals (1s, 2s, 4s, 8s…) with added jitter. Reduce overall request frequency and consider request queuing.

Is the Retry-After header required with 429?

RFC 6585 does not mandate it, though servers should include it. Many APIs omit it. If absent, clients must implement their own backoff strategy.

Does 429 affect SEO?

Yes. If Googlebot consistently receives 429 responses, it will reduce crawl frequency or stop crawling affected URLs. Sustained 429s can cause pages to fall out of the index or delay indexation of new content.

What is the difference between 429 and 503?

429 is client-specific: you sent too many requests. 503 is server-wide: the server is refusing all traffic because it is overloaded or in maintenance. Both may include Retry-After, but 503 affects all clients, not just the one that triggered the limit.

Related resources

On this site: HTTP 429 rate limiting and retry logic guide · HTTP 503 Service Unavailable · HTTP 408 Request Timeout · HTTP 401 Unauthorized · All 4xx client errors

Comparisons: 429 vs 503 · 425 vs 429 · 503 vs 429

Standards: RFC 6585 §4 · IANA HTTP Status Code Registry · MDN Web Docs: 429