429 Too Many Requests

429 Too Many Requests means the client has exceeded a rate limit — too many requests in a given window. The response should include a Retry-After header saying when to try again, and often RateLimit-* / X-RateLimit-* headers describing the quota:

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

Common causes

• A runaway loop — a retry loop without backoff hammering an endpoint (which then rate-limits it, which triggers more retries…)
• Shared IPs — NAT, corporate proxies or serverless egress pools where many tenants share one IP and burn one IP-based quota
• Fan-out on page load — a frontend firing dozens of API calls per view
• Batch jobs without pacing — imports and syncs that blast an API at full speed instead of respecting documented limits
• Scrapers and abuse — in which case the 429 is your protection working

Handling 429 correctly (client side)

1. Honor Retry-After — it's a number of seconds or an HTTP date; don't retry earlier.
2. Exponential backoff with jitter — when there's no Retry-After, back off exponentially and add randomness so a fleet of clients doesn't synchronise into waves.
3. Never retry 429 immediately — that converts a rate limit into an outage.
4. Watch the remaining-quota headers and slow down before hitting zero.

Handling it server side

Rate limits protect capacity, but a growing background rate of 429s to legitimate users means limits are tuned too low or clients are misbehaving — either way you want to see the trend, not discover it from complaints.

Debugging

Reproduce with the free API tester and read the rate-limit headers to see the actual quota and window. When monitoring endpoints that are themselves rate-limited, check the interval math: a monitor every 30 seconds consumes ~2,880 requests/day against your quota — schedule accordingly, or monitor a dedicated health endpoint excluded from limits.