Error 429
An error 429 pops up when you've hit the request limit set by a server for a specific endpoint within a time window. It's the server's way of saying, 'You're asking for too much, too fast.' The API's throttling your requests, and you need to back off before trying again.
Quick Facts
- Also known as
- Rate Limit Exceeded, Too Many Requests, HTTP 429
- IP source
- Triggered server-side; mitigated via rotating residential IPs drawn from a 2.5M+ pool
- Detection risk
- High when sending repeated requests from a single IP without rotation
- Typical use
- Web scraping, API data collection, automated browsing at scale
- Price range
- $0.27–$0.79/GB with 1TB free to start, no credit card required
How a error 429 works
The server keeps tabs on how often you're hitting it, using your IP or API key, against a rate limit like 100 requests per minute. Once you exceed that, requests get shut down, and you see a 429. If the API's set up right, it sends back a Retry-After header telling you how long to wait. You should read that header and use exponential backoff, doubling the wait time after each 429 until it works. A common backoff formula is min(cap, base * 2^attempt), where base is the Retry-After time in seconds. Cap it to avoid endless delays. If you skip backoff and keep hitting the endpoint, you're just digging a deeper hole. Usually, servers reset the rate-limit window once you stop hitting them.
Error 429 vs. Error 403
A 429 is rate-based and temporary. You can come back after a cooldown. A 403? That's permanent. The server's decided you're out, and it doesn't care about your timing or how many requests you're sending.
Why this is different
Advantages
- Allows legitimate traffic to resume after backoff, unlike a 403, which is a permanent ban with no retry path
- Retry-After header eliminates guesswork: instead of polling every 5 to 60 seconds hoping the window resets, your client waits the exact server-specified interval
- Keeps servers stable under load by shedding excess requests before they queue and cause cascading timeouts
- Standardized across APIs, so one retry handler covers Google, OpenAI, Twitter, and any other RFC 6585-compliant endpoint
Tradeoffs
- Disrupts time-sensitive scraping or data pipelines
- Retry delays compound across many requests
- Not all servers return Retry-After header
- Shared IPs may trigger limits from others' usage
Examples in practice
Real-world deployments of Error 429 , where it works and where alternatives win.
Google Search API Limits
Google's Custom Search JSON API caps free-tier usage at 100 queries per day, returning error 429 on every request beyond that threshold. The standard fix is exponential backoff starting at the Retry-After value, typically 60 seconds, then doubling on each successive 429 until the daily quota resets at midnight Pacific. Caching repeated queries client-side cuts API calls by 40 to 60% in most price-monitoring workloads.
Amazon Product Page Scraping
Amazon enforces roughly 10 requests per minute per IP on product and pricing pages, returning error 429 shortly after that threshold. Rotating through 100+ residential IPs allows parallel scraping at an effective throughput of around 1,000 requests per minute, the same volume that would trigger immediate blocks from a single IP.
OpenAI API Token Quotas
OpenAI returns error 429 when an app exceeds its token-per-minute quota: 90,000 TPM on the Tier 1 plan. Exponential backoff with jitter (random 0 to 1 second added to each wait interval) and batching requests into a queue reduces failed calls from near-100% under burst load to under 2% in steady state.
Yahoo Finance Data Collection
Yahoo Finance cuts off unauthenticated requests at roughly 2,000 per hour per IP before returning error 429. Spreading requests across multiple IPs and inserting 200 to 500ms of jitter between calls keeps per-IP request rates below the detection threshold and restores consistent access to pricing feeds.
Uptime Monitoring Polling Loops
Datadog and UptimeRobot can trigger error 429 responses when polling an endpoint every 30 seconds across 50+ monitors, resulting in 100 requests per minute hitting a single target from a small set of monitor IPs. Configuring check intervals above 60 seconds and alerting on 429 spikes catches the problem before it cascades into false-positive downtime alerts.
Twitter v2 API Read Limits
Twitter's v2 API enforces a 500,000 tweet read limit per month per app, issuing error 429 once exceeded. The response includes x-rate-limit-reset as a Unix timestamp; client code should parse that value directly rather than guessing at the 15-minute window, since Twitter resets limits on a rolling basis, not at fixed clock intervals.
Common misconceptions
Common myths about Error 429 , and what is actually true.
| Myth | Reality |
|---|---|
"A 429 error means the server is down" | A 429 response actually confirms the server is healthy and actively processing requests , it is explicitly rejecting yours because you have sent too many, not because anything is broken on the server side. |
Need Error 429s?
2.5M+ residential IPs, 195+ countries, from $0.27/GB.
