HTTP 429 Too Many Requests is the status code a server sends when a client has exceeded its rate limit — it's a pacing objection, not a permissions or content problem. The request itself was valid; there were just too many of them in the current window.
429 is defined in RFC 6585 specifically for rate limiting, which makes it the cleanest signal in a family of overlapping error codes: a 403 usually means the request itself was judged (often by an anti-bot system) as not allowed regardless of volume, while Cloudflare's 1015 is the CDN's edge enforcing a rate rule before the request ever reaches the origin server. A 429, by contrast, comes from the origin application's own rate limiter — the request got through, and the app itself said slow down.
That distinction changes the fix: a 403 usually needs a different identity (fingerprint, IP), while a 429 just needs pacing — reduce request rate, wait, and retry. Treating a 429 like a block and switching IPs immediately skips the simpler, correct fix.
A well-behaved 429 response includes a Retry-After header, either as a number of seconds or an HTTP date, telling the client exactly when it's safe to try again. Respecting it is the difference between a brief pause and a client that keeps tripping the same limit and getting escalated to a harder block.
Not every server sends the header. When it's absent, exponential backoff — doubling the wait after each consecutive 429 — is the standard fallback, since guessing a fixed retry interval either wastes time waiting too long or trips the limit again by retrying too soon.
How Crawlora handles this
Crawlora reads and respects Retry-After internally, backs off automatically when it's missing, and distributes retries across the proxy pool so a rate limit on one IP doesn't stall the whole request — and a 429 against the target site isn't billed to you.
Related reading
Glossary
FAQ
A 429 means you're sending requests too fast — the fix is to slow down or wait for Retry-After. A 403 means the request was refused outright, usually by anti-bot detection, and no amount of waiting fixes it — you need a different fingerprint or IP.
Whatever the Retry-After header says, if present. If it's absent, use exponential backoff — start with a short wait and double it on each consecutive 429 — rather than guessing a fixed delay that might be too short or unnecessarily long.
It can. Ignoring the rate limit and retrying immediately keeps tripping the same rule, and some servers escalate repeat offenders to a longer ban or a harder block like a 403. Respecting the pacing signal the first time is faster in the long run.
Beyond 429 Too Many Requests, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.