Rate limit
A rate limit is the ceiling on how fast an API will accept requests. It protects the service from one noisy caller and protects you from a runaway loop. A good one tells you where you stand on every response and how long to wait when it refuses, so a client can slow down before it is turned away rather than after.
At a glance
- Category
- API behaviour
- Reported on
- Every response, in headers naming the limit and what remains
- Refusal
- A 429 status, with the seconds to wait
- Scope
- Per team, shared by every key on it
- Correct response
- Back off and retry, rather than retry immediately
How it works
The service counts requests against a window and compares the count with your ceiling. Every response carries headers naming the limit, how much of it is left and when the window resets, so a client can read its own position without guessing. When the count is exceeded the request is refused with a 429 status and a header saying how many seconds to wait. Nothing about the refused request is processed, so retrying after the wait is safe.
Why it matters
A limit that only announces itself by refusing is a limit you discover during an incident. Reporting the remaining allowance on every response turns it into something a client can plan around: a batch job can pace itself, and a queue worker can slow down gracefully instead of hammering a service that is already saying no. On the service side it is what stops one caller's bug becoming everybody's outage, and it is why a shared allowance is usually per team rather than per key: a limit you can raise by minting another credential is not a limit.
Example
A nightly job sends several thousand messages. It reads the remaining allowance from each response and pauses when it falls low, so the job finishes without ever being refused. A second service has a bug and loops, exhausts its allowance in seconds and starts receiving 429s with a wait of a few seconds; it sleeps for that long and retries, and the rest of the team's traffic is unaffected.
Common mistakes
- 01Retrying a 429 immediately, which spends the next window's allowance on requests that will also be refused.
- 02Ignoring the remaining-allowance header and discovering the ceiling only when a job fails halfway through.
- 03Assuming a limit is per key when it is per team, so adding a second key does not double anything.
- 04Running several workers that each pace themselves independently, so the team's shared allowance is exhausted by their combined traffic.
In Rasket
The limit is per team and shared by every key on it, every response carries the headers, and a refusal says how many seconds to wait. Rate limits
Related terms
Frequently asked questions
What should my client do when it is refused?
Wait for the number of seconds the response names, then retry. Adding a little random jitter is worthwhile when several workers would otherwise wake at the same moment.
Does a refused request still count?
The request was not processed, so nothing happened that you need to undo. Whether the attempt itself counts against the window depends on the service, which is why backing off rather than retrying tightly is the safe pattern.
Can I raise the limit?
Usually, for accounts whose traffic justifies it. Pacing a job against the headers is worth doing first, because most limits are hit by bursts rather than by sustained volume.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.