OneWebDesk

API Rate Limit Calculator

Calculate safe call volume and burn-down time from per-minute/hour limits and concurrency.

When an API enforces a rate limit like “100 requests per minute,” how fast can you send your own requests without hitting 429 (Too Many Requests)? Enter the limit (request count) and the window (seconds), and this calculator returns the allowed throughput per second, the minimum safe interval between requests (in ms), and how long it takes to send N requests safely.

It helps you set the right throttle when designing batch jobs, crawlers, webhook retries, or bulk-send scripts. It also shows how the per-worker interval changes as you add concurrent workers. To analyze response latency by percentile, see Latency Percentile Calculator; to craft a request and test it, use cURL Command Builder.

Rate / interval
Allowed rate1.6667 req/s
Minimum safe interval600 ms
Per-worker interval600 ms (1 workers)
Plan for sending N

N exceeds one window's limit. You must split the sends across multiple windows to avoid 429.

Time to send N300 s (05:00)
Windows needed5
Within limit in one windowNo

The core formulas

A rate limit is defined as “limit (requests) per window (seconds).” Everything else derives from it.

  • Allowed rate = limit ÷ window (req/s)
  • Minimum safe interval = window ÷ limit (s) = 1000 × window ÷ limit (ms)
  • Per-worker interval = concurrency × (window ÷ limit) — more workers means each must send more slowly to keep the total rate constant.
  • Time to send N = N ÷ (limit ÷ window) = N × window ÷ limit (s)

Example: 100 requests/minute

With limit 100 and a 60-second window, the allowed rate is about 1.67 req/s and the minimum interval is 600 ms. Spacing each request at least 600 ms apart is safe.

  • Sending 500 requests takes 500 × 60 ÷ 100 = 300 s (=05:00).
  • Exceeding the limit of 100 inside one 60-second window triggers 429. For 500 requests you need at least ceil(500/100)=5 windows.
  • With 4 concurrent workers, the per-worker interval should be 4 × 600 ms = 2400 ms so the combined rate stays under the limit.

Bursts and token buckets

Many APIs allow a burst on top of the average rate. This tool assumes a conservative steady rate, so on a token-bucket API that permits bursts you may be able to push harder. Sticking to the safe interval, though, almost always avoids 429 regardless of the limiter design.

Frequently asked questions

What if I set the limit or window to 0?
Both the limit and the window must be greater than 0 (to avoid division by zero). If either is 0 or less, the tool shows guidance instead of a result.
Do I have to obey the minimum safe interval?
On a token-bucket API that allows bursts you can briefly send faster. But honoring the safe interval avoids 429 under any limiter design, so it is the safest choice.
Why does the per-worker interval grow with more workers?
Because the combined rate is fixed at the limit. With C workers sending in parallel, each must space requests C times wider so the total still equals the limit.
What should I look at when N exceeds the limit?
It means you cannot send everything in a single window. Use the number of windows needed, ceil(N/limit), and the total send time to spread the work across multiple windows.
Are my inputs sent to a server?
No. All calculations run entirely in your browser, and the limit, window, request count, and worker count you enter are never transmitted or stored anywhere.

Related tools

HTTP / API