What is rate limiting?
The automation that worked fine in testing starts failing at scale, and the fix isn't more retries. It's a queue.
Rate limiting
throttling
Rate limiting is a control a service applies to cap how many requests, or tokens, a client can send in a fixed time window. Cross the cap and the extra requests get rejected, usually with an HTTP 429 status, until the window resets.
RFC 6585 defines the status code plainly. It "indicates that the user has sent too many requests in a given amount of time." That is the entire mechanism. A provider sets a ceiling and counts your requests against it. Cross the ceiling and every call fails until the clock resets.
The ceiling is rarely one number. OpenAI's API, for example, tracks limits per model across several dimensions at once: requests per minute, tokens per minute, and daily versions of both. You can be under your request limit and still get a 429 because you sent too many tokens in the same window.
A well-behaved API tells you where you stand before you hit the wall. OpenAI returns headers on every response, including x-ratelimit-remaining-requests and x-ratelimit-remaining-tokens. A client can read those and slow down before the 429 arrives, not after.
429 is a signal, and most clients ignore it
A 429 tells you exactly what to do next, if you read the response. MDN defines Retry-After as "how long the user agent should wait before making a follow-up request," given in seconds or a fixed date. OpenAI's docs confirm the API attaches this header to a 429, stating precisely how many seconds to wait.
Most integrations we inherit ignore that header. They retry immediately, hit the same limit, retry again, and turn one slow patch into a pile-up that looks like an outage. The provider did not fail. A client kept knocking on a door it was told was closed for another ten seconds.
Clever error handling bolted on afterward doesn't fix it. A queue in front of the call, from the start, does. Requests get paced against the known limit. A burst waits its turn instead of firing all at once and eating a wall of 429s.
- Request queuedPaced against the known limit, not fired blind.
- SentWithin the current window's remaining budget.
- 429 returnedBudget exhausted before this one landed.
- Retry-After readClient waits the stated seconds, not zero.
- Window resetsBudget refills; queue resumes sending.
The queue is what turns a hard ceiling into a pace, instead of a wall the automation runs into every few minutes.
Common questions
01What does a 429 error mean?
A 429 means the server received too many requests from you in a given time window and rejected this one. RFC 6585 defines the code for exactly this case. It's not a bug in your request; it's a rate limit you crossed. Slow down. Nothing about the request itself needs to change.
02How does the Retry-After header work?
Retry-After is a response header that tells you how long to wait before trying again. MDN documents its value as either a number of seconds or a specific date. Many APIs, including OpenAI's, attach it to a 429 response. Reading it and waiting that long fixes most rate-limit failures.
03How do I handle API rate limits in an automation?
Put a queue in front of the calls instead of firing them as fast as the workflow allows. Track the provider's stated limits, whether that's requests per minute or tokens per minute, and pace sends to stay under them. When a 429 does arrive, read Retry-After and wait that long before the next attempt, rather than retrying immediately.
04Is rate limiting the same as throttling?
In practice, yes. "Throttling" is the more common term for what a client experiences; "rate limiting" describes the control the server applies. Both refer to the same mechanism: a cap on requests per window, enforced with a 429 once you cross it.
Related terms
- API integration →Where we design the queueing and pacing around a provider's limits before launch, not after the first outage.
- OpenAI API →A production review of the API whose rate-limit headers this page draws on.
- Webhook →The other direction of the same problem: a provider pushing events at you faster than you can process them.
