Skip to content
HTTP errors in web scraping and automation · error message

HTTP: 429 Too Many Requests

RetryableHTTP 429Rate limiting (429)

Last verified

The exact message
requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for url: https://example.com/api/items

What 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

  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 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

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.