HTTP 429 Too Many Requests

What HTTP 429 means

HTTP 429 Too Many Requests means the client exceeded a rate limit — per IP, per API key, per user or per endpoint. Well-behaved servers include a Retry-After header (seconds or a date) and often X-RateLimit-* headers describing the quota.

For clients the correct reaction is always the same: back off. Retrying immediately makes it worse and can escalate a temporary throttle into a ban.

Common causes of 429 errors

• An API client polls too frequently or bursts above its quota.
• Web scraping without delays between requests.
• A bug: a retry loop without backoff hammering the same endpoint.
• Shared IP (office NAT, VPN, serverless egress) where combined traffic crosses the limit.
• Login endpoints throttling repeated attempts as brute-force protection.

How to fix it as a client/developer

• Honor Retry-After exactly; if absent, use exponential backoff with jitter (e.g. 1s, 2s, 4s, 8s…).
• Read the API's X-RateLimit-Remaining/Reset headers and pace requests proactively.
• Batch requests and cache responses instead of re-fetching identical data.
• Spread load across time, not across throwaway IPs — evading limits usually violates the API's terms.

How to fix it as an API owner

• Always send Retry-After and quota headers so clients can behave.
• Rate-limit by key/user rather than bare IP where possible to avoid punishing shared networks.

Example response

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0

{"error":"rate_limited","retry_after":30}

FAQ