HTTP 429 Too Many Requests

HTTP 429 Too Many Requests indicates the request was not fulfilled due to a client-side issue (inputs, credentials, permissions, or request shape). It usually requires changing the request or client behavior rather than retrying blindly.

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

curl -i "https://httpstatus.com/api/status/429"
Try in playground

Meaning

The user has sent too many requests in a given amount of time.

What it guarantees
  • The request was not fulfilled due to a client-side issue.
  • A rate/quota policy blocked the request.
What it does NOT guarantee
  • Retries will succeed without changing request inputs.
  • The server is healthy; it may still be failing for other reasons.

When to use this status

  • Per-IP or per-token throttling to protect the service.
  • Quota enforcement where clients must back off.
  • Abuse protection when requests must be slowed down.

When NOT to use this status (common misuses)

Using 400 for authentication/authorization failures.
Clients cannot distinguish validation vs auth; retry/login flows break.
Using 404 to mask permission issues everywhere.
Monitoring misclassifies access bugs; SEO can degrade if real pages appear missing.
Returning 4xx for server-side bugs.
Clients stop retrying; incidents are masked as client behavior.
Returning 429 without Retry-After/backoff guidance.
Retry storms amplify throttling and degrade availability.

Critical headers that matter

Content-Type
Defines error body format (JSON/text/problem+json).
Clients can’t parse structured errors; observability loses fidelity.
Cache-Control
Prevents caching transient errors unless intended.
CDNs cache failures; prolonged user-visible outages.
Retry-After
Tells clients when to retry safely.
Clients retry too aggressively; throttling becomes less effective.

Tool interpretation

Browsers
Displays an error state; devtools exposes status and headers. Cache headers can accidentally cache error documents.
API clients
Classifies as failure; retry policy depends on idempotency and code class. Structured errors improve handling.
Crawlers / SEO tools
Persistent failures reduce crawl rate; soft-404 patterns cause indexing instability.
Uptime monitors
Typically alerts based on rate/threshold. Consistent classification reduces false positives.
CDNs / reverse proxies
May cache errors if misconfigured; respects Cache-Control and can serve stale on origin failure.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
  • Error cacheability and retry guidance signals
Correctness warnings
  • Missing Retry-After increases retry storms and destabilizes clients.

Guided Lab outcome

  • Reproduce HTTP 429 Too Many Requests using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
  • Identify the minimum request changes required to move from client error to success.

FAQ

Should clients retry on HTTP 429?
Retry after the indicated window (Retry-After) with exponential backoff and jitter.
Is HTTP 429 cacheable?
Generally should not be cached unless explicitly intended; use Cache-Control to prevent sticky failures.
Which headers matter most for HTTP 429?
Content-Type and Cache-Control are the baseline. Some codes also require Location, WWW-Authenticate, or Retry-After.
How does this affect monitoring?
Client errors should be tracked as contract/UX issues; page only if widespread.
How does this affect crawlers/SEO?
SEO impact is driven mostly by cacheability, canonical stability, and content correctness.
What should error responses include?
A stable, machine-parseable format with correlation IDs and actionable messages.

Client expectation contract

Client can assume
  • The request failed due to client-side inputs or policy.
Client must NOT assume
  • Retries without changes will succeed.
Retry behavior
Retry after Retry-After (if present) with exponential backoff and jitter.
Monitoring classification
Client error
Use payload and header checks to avoid false positives; cacheability depends on Cache-Control/ETag/Vary.

Related status codes

428 Precondition Required
The origin server requires the request to be conditional.
431 Request Header Fields Too Large
The server is unwilling to process the request because its header fields are too large.
503 Service Unavailable
The server is currently unavailable (overloaded, down for maintenance, or rate limiting). Should include Retry-After header when possible.
500 Internal Server Error
A generic error message, given when an unexpected condition was encountered.