HTTP: 429 Too Many Requests
Last verified
requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for url: https://example.com/api/itemsWhat it means
429 is defined in RFC 6585: the client has sent too many requests in a given amount of time. It is the clearest message a site can send to an automated client, because it says exactly what to change. The server may include a Retry-After header, either as a number of seconds or as an HTTP date, telling you when you may try again.
A browser rarely sees 429 because a person clicks a few pages a minute; a script that loops over hundreds of URLs can cross the threshold in seconds. Limits can be counted per IP, per API key, per account or per endpoint, and many APIs return headers such as X-RateLimit-Remaining so you can see your budget.
What is not wrong: your request is valid and you are not banned. Keep sending at the same pace, though, and many sites escalate to a 403 or a longer block.
What it looks like
import time, requests
def get(url, attempts=5):
for i in range(attempts):
r = requests.get(url, timeout=30)
if r.status_code != 429:
return r
wait = r.headers.get("Retry-After")
time.sleep(int(wait) if wait and wait.isdigit() else 2 ** (i + 1))
r.raise_for_status()Why it happens
- A loop or concurrency setting sends requests faster than the site's published or unpublished limit.
- Several jobs or workers share one IP or API key, so their combined rate exceeds the limit.
- Retries fire immediately after failures, multiplying traffic exactly when the server is asking you to back off.
- The API counts a burst limit (per second) separately from a sustained limit (per hour or day).
How to fix it
- Stop sending to that host immediately when you receive 429.
- Read Retry-After: if it is an integer, wait that many seconds; if it is a date, wait until then.
- If there is no Retry-After, back off exponentially (for example 2, 4, 8, 16 seconds) with random jitter, and cap the number of attempts.
- Lower concurrency to one or two requests at a time per host and add a fixed delay between requests.
- Check the API documentation for the documented limit and any rate-limit headers, and stay comfortably under it.
- If you need more throughput, ask the provider for a higher quota or a bulk export rather than spreading requests across identities.
How to stop it recurring
Design for the limit up front: a per-host rate limiter, a small worker pool, caching, and conditional requests (If-Modified-Since, ETag) so unchanged pages are not downloaded again. Log rate-limit headers so you see the budget shrinking before it runs out. Behind Cloudflare, the equivalent block page is error 1015.
Official documentation: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429. See all HTTP error messages.
Related errors
Definitions
- CAPTCHACAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge-response m
- Cloudflare Bot ManagementCloudflare Bot Management is the set of Cloudflare features (Bot Fight Mode, Super Bot Fight Mode and the Ente
- DataDomeDataDome is a commercial bot-protection service that scores every request to a website, app or API in real tim
- HUMAN Security (PerimeterX)PerimeterX, now HUMAN Security's Bot Defender after a 2022 merger, is a bot-protection service that scores eve
- User AgentA user agent is a string that browsers send with every HTTP request identifying the browser type, version, and
- AI Web ScraperAn AI web scraper is an AI-powered data extraction tool that understands page structure, identifies relevant d
- Data ScrapingData scraping is the broad practice of programmatically extracting data from any digital source — websites, ap
- Web CrawlerA web crawler (also called a spider or bot) is a program that systematically browses the internet by following
Quick answers
What does "429 Too Many Requests" mean in HTTP?
429 is defined in RFC 6585: the client has sent too many requests in a given amount of time. It is the clearest message a site can send to an automated client, because it says exactly what to change. The server may include a Retry-After header, either as a number of seconds or as an HTTP date, telling you when you may try again.
How do I fix "429 Too Many Requests"?
1. Stop sending to that host immediately when you receive 429. 2. Read Retry-After: if it is an integer, wait that many seconds; if it is a date, wait until then. 3. If there is no Retry-After, back off exponentially (for example 2, 4, 8, 16 seconds) with random jitter, and cap the number of attempts. 4. Lower concurrency to one or two requests at a time per host and add a fixed delay between requests. 5. Check the API documentation for the documented limit and any rate-limit headers, and stay comfortably under it. 6. If you need more throughput, ask the provider for a higher quota or a bulk…
Retries and timeouts without writing the loop
Autonoly's HTTP Request node and browser steps have per-node retries, timeouts and continue-on-fail, so a transient 429 or 503 can back off instead of failing the run. It has no proxies or IP rotation: if a site blocks automated traffic, that block applies to Autonoly too.
Also see Error handling in workflows.