429 Too Many Requests means you got rate limited: you sent more requests than the server allows in a given window, and it's telling you to back off. It's a 4xx client code, and it's usually the server doing its job — protecting itself from overload, scraping, and brute force.
Why servers return 429
- Rate limiting — the API caps requests per key/IP/user per window.
- Quota — you've used your plan's allowance.
- Abuse protection — too many login attempts triggers a lockout (this is a feature, not a bug).
- Shared IP — you're behind a NAT/proxy and someone else used up the budget.
How to fix it — as a client / API consumer
- Honor
Retry-After. The response tells you how long to wait — respect it. - Use exponential backoff. Retry after 1s, 2s, 4s, 8s… with jitter, not in a tight loop.
- Cache and batch. Don't re-request data you already have; combine calls where the API allows.
- Check your limits. Read the API's documented rate limits and the
X-RateLimit-*headers.
How to set it up — as the API owner
- Rate-limit by API key or user, not just IP, so shared IPs don't punish innocent clients.
- Always return a
Retry-AfterandX-RateLimit-*headers so good clients can behave. - Set limits generous enough for real usage but tight enough to stop abuse.
- Rate limiting is a core security control — it's on the API security checklist precisely because missing it enables brute force and credential stuffing.
The two sides of a 429 spike
If your own users are hitting 429s, your limits are probably too tight. If your auth endpoints are throwing 429s, that may be your rate limiter working — blocking a brute-force attempt in progress. Both are worth seeing in real time.
Nurbak Watch tracks status codes per endpoint, so a surge of 429s — whether it's legit users you're throttling or an attack you're absorbing — shows up immediately.