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 limitingthe API caps requests per key/IP/user per window.
- Quotayou've used your plan's allowance.
- Abuse protectiontoo many login attempts triggers a lockout (this is a feature, not a bug).
- Shared IPyou'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 workingblocking a brute-force attempt in progress. Both are worth seeing in real time.
Rate limiting slows brute force down, but it doesn't fix an endpoint that never checks auth in the first place. Nurbak's AI pentester scans your repo for missing auth checks and other exploitable bugs, and can open a PR with the fix. Your first scan is free.