What is an API rate limit?

What does 429 Too Many Requests mean?

429 Too Many Requests is the HTTP status an API sends back when a client has gone over its rate limit. The code was defined in RFC 6585 in 2012, and it means “slow down”, not “your request is wrong”: the same request works once the window has passed.

Most APIs say how long to wait in a Retry-After header, defined in RFC 9110 as a number of seconds or a date. Many also send headers on every response that show how much of the budget is left, like the ones in the table above, so that a well-behaved client never sees the 429 at all.

How do API rate limits work?

An API counts the requests each client sends over a window of time, and refuses the ones above a set number until the window moves on. Every rate limit has three parts.

• A number and a window: so many requests a second, a minute or a day.
• A way of counting. A fixed window resets on the clock, every minute on the minute. A sliding window looks back over the last second or minute at each request, so there is no reset to wait for. A token bucket refills a little at a time and tolerates short bursts.
• A scope: the limit can apply to one API key, to a whole account, to an IP address or to each endpoint separately.

Services set limits to protect themselves from runaway scripts, to share capacity fairly between customers, and to price their plans. For the client, one consequence matters most, and the simulator below shows it.

Try it

Send faster than the limit, and see what comes back

1. Second 1
2. Second 2
3. Second 3
4. Second 4
5. Second 5

200 OK 429 Too Many Requests

In 5 seconds, 50 requests go through and 25 come back as 429. Sending faster does not finish sooner: the work still moves at 10 a second, and 1,000 requests still take 1 min 40 s.

A 5-second run, requests spread evenly, counted over a one-second window, with no queue on the API side.

How do you handle a 429 error?

You handle a 429 error by slowing down, not by retrying harder. Five habits do it:

1. Wait what the API asks. Read Retry-After and pause that long. Retrying at once spends the next window too.
2. Throttle on your side. Send at the limit, not above it. Requests that come back as 429 do not make a job finish sooner; they only add retries.
3. Retry what is worth retrying. A 429 or a 503 can be sent again as it is. A 400 or a 422 fails the same way until you change the request.
4. Spread the work. When limits are counted per endpoint, calls to two different endpoints do not compete, so an enrichment job can run its email and company lookups side by side.
5. Set the pace in your tools. In Clay, n8n or Make, the batch size and the delay between requests are the throttle.

Rate limits are one of two meters on a data API. The other one counts what you use, often in API credits.

API rate limiting vs throttling: what is the difference?

Rate limiting and throttling are often used for the same thing. Strictly, they describe two reactions to the same excess.

	Rate limiting	Throttling
Above the limit	The request is refused (429)	The request is slowed down or queued
Who applies it	The API	The API, or the client on purpose
What the client gets	An error to handle	A slower answer

Client-side throttling is the usual cure for server-side rate limiting: a client that paces itself at the limit never gets refused.

How does BlitzAPI count its API rate limit?

BlitzAPI counts its rate limit per endpoint and per account, over a sliding one-second window, with no queue: a request above the limit gets a 429 with Retry-After: 1 at once. The limit depends on the plan (see pricing), and the exact value for a key comes back from GET /v2/account/key-info.

The Python and TypeScript SDKs on the developer toolkit page keep one client under the limit on each endpoint and retry a 429 on their own.