API Rate Limit Calculator
Size a request rate that fits inside a quota, retries included.
What you provide
Retries count against the quota. 1.1 assumes about one request in ten is retried.
Result
3.33 requests a second per client, one every 300 ms
Two things break a plan that looks fine as an average. Fixed windows reset on the clock rather than sliding, so firing a full allowance at the end of one window and again at the start of the next sends double the intended rate in a couple of seconds. And retries count against the quota, which means a burst of failures can consume the budget that would have let them succeed. Read the response headers instead of guessing: most APIs return the remaining count and a reset time, and honouring the Retry-After header on a 429 is more reliable than any client-side schedule.
- Quota
- 1,000 per 60s
- Average rate
- 16.67 req/s
- Safe rate (20% held back)
- 13.33 req/s
- Per clientAcross 4 clients
- 3.33 req/s
- Interval between requests
- 300 ms
- Requests including retries
- 5,500
- Time to finish the job
- 6.9 min
- Windows consumed
- 5.5
What this cannot tell you
- Planning arithmetic on the numbers you enter. It does not call any API or read your usage.
- Providers enforce limits differently, using fixed windows, sliding windows or token buckets. The safe rate here is deliberately conservative because a fixed window can allow double the average rate across a boundary.
Take this with you
How this calculation works
The quota is converted to an average rate, a safety margin is held back, and what remains is divided among the clients sharing it. That gives a per-client interval you can put straight into a scheduler. If you enter a job size, the retry multiplier is applied and the finish time is estimated from the safe rate, which is usually the number that decides whether a nightly job is viable at all.
What the results mean
- Safe rate
- The average rate minus your margin. The margin exists because fixed windows reset on the clock, and a burst across a boundary can send double the intended rate in a moment.
- Interval between requests
- How long each client should wait between calls. Feeding this into a scheduler is more reliable than counting requests and hoping.
- Requests including retries
- Retries consume quota like any other call, which is what turns a burst of failures into a longer outage.
Common problems and fixes
- Throttled despite staying under the average rate
- The window is probably fixed rather than sliding. Sending an allowance at the end of one window and again at the start of the next puts double the rate into a few seconds, and the limiter sees the burst rather than the average. Spread requests evenly and hold back a margin, or use a token bucket on your side to smooth the output.
- A retry storm makes an outage last much longer
- Add exponential backoff with jitter, and honour the Retry-After header when one is returned. Without jitter, every client retries at the same moment and recreates the spike that caused the failure. A circuit breaker that stops calls entirely after repeated failures is worth adding for anything that runs unattended.
Frequently asked questions
How do I find the real limit?
Read the response headers rather than the documentation. Most APIs return the limit, the remaining count and a reset timestamp on every response, and those reflect what is actually being enforced for your account, which is sometimes different from what is published.
What is the difference between a fixed and a sliding window?
A fixed window counts requests in each clock interval and resets sharply, which allows double the rate around a boundary. A sliding window counts over the trailing interval continuously and does not have that edge. Token buckets are different again: they allow a genuine burst up to the bucket size and then settle to a refill rate.
Should I run requests in parallel?
Only up to the point where the total rate stays inside the budget. Parallelism does not increase the quota, it just consumes it faster, and it makes bursts more likely. Where an API supports batch endpoints, one call carrying many items usually counts as one request, which is a far better use of the quota.
Put this on your own site
Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.
<iframe src="https://runthetests.com/embed/api-rate-limit-calculator/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="API Rate Limit Calculator" loading="lazy"></iframe>
Preview it at https://runthetests.com/embed/api-rate-limit-calculator/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.