HTTP 429 Too Many Requests
HTTP 429 is the standard status code for rate limiting responses, defined in RFC 6585. It tells the client that it has sent too many requests in a given time window and should slow down. The response should include a `Retry-After` header specifying how many seconds to wait before retrying, and optionally `RateLimit-*` headers indicating the current quota state.
**Minimal correct 429 response:**
```
HTTP/1.1 429 Too Many Requests
Retry-After: 30
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 60
Content-Type: application/json
{"error": "rate_limit_exceeded", "retry_after": 30}
```
Formula
429 = Too Many Requests. Must include Retry-After header for intelligent client backoff.Why it matters in practice
Many services return 503 (Service Unavailable) for rate limit responses, which is semantically incorrect — the service is available, the client is sending too many requests. 503 also triggers more aggressive client retry behaviour (it implies a server fault, not a client fault), potentially worsening a retry storm. 429 with a correct `Retry-After` header gives well-behaved clients exactly the information they need to back off appropriately.
Common mistakes
- •Returning 429 without a Retry-After header — clients cannot implement intelligent backoff without knowing when to retry.
- •Setting Retry-After to a very short value (< 1 second) — this invites immediate retries and can cause retry storms.
- •Not differentiating between per-client 429 (you specifically are rate-limited) and global 429 (the service is overloaded) — they require different client responses.
Related Terms
Retry-After header
Specifies how long client should wait before retrying.
RateLimit headers (IETF)
Standardized headers for communicating quota information.
X-RateLimit headers
Legacy de facto standard for rate limit state communication.
Exponential backoff
Retry wait times grow multiplicatively after each failure.