Technology & Developers
API Rate Limit Calculator
Convert a rate limit between time windows, check your request rate against it, and size the limit your users actually need.
Free to useNo sign-up requiredNo watermarkRuns in your browser
API limits are quoted in whatever window suits the provider - 10 requests a second, 1,000 an hour, 10,000 a day - while your traffic is usually measured in something else. This calculator puts both on the same footing: it converts the limit into every common window and compares it with the rate you are sending.
It also answers the planning question: if a number of users share one key and each makes so many requests, what limit do they need in total, and how much of the allowance does each get? If the API uses a token bucket, enter the burst size to see how long a spike can run before requests start being refused.
How this tool works
Enter the limit
Requests allowed and the window - for example 1,000 per 1 hour. Presets cover common shapes.
Add your current rate
The steady rate you send now or plan to, in requests per second, minute, hour or day.
Describe the target traffic
How many users share the limit and how many requests each makes, per their own window.
Optionally add a burst size
For token-bucket APIs, the bucket capacity. Leave it empty if you do not know it.
Read the verdict
Within the limit, current traffic over it, or target traffic needing a bigger limit - with the numbers.
How it works
Every rate is converted to requests per second first. The allowed rate is the limit divided by the window length in seconds, then multiplied back up to per-minute, per-hour and per-day figures.
Your current rate is multiplied by the window to give requests per window, and compared with the limit. If it is higher, the time to hit the limit is the limit divided by your rate - assuming a fresh fixed window and steady traffic.
Target traffic is users × requests per user, converted into the limit’s window. That is the limit you would need, and the allowance per user is simply the limit shared evenly between them.
With a burst size, the calculator models a token bucket that starts full and refills at the allowed rate. If you send faster than the refill, the bucket empties after burst ÷ (your rate − refill rate) seconds.
Common use cases
- Checking whether a batch job or data sync will stay under a third-party API’s limit.
- Deciding how many users or tenants one API key can serve before it needs an upgrade.
- Choosing a sensible per-user or per-IP limit for your own API.
- Converting a limit quoted per hour into the per-second rate a client-side throttle needs.
- Sizing how long a traffic spike can last before 429 responses begin.
Fixed window, sliding window and token bucket
A fixed window counts requests in calendar blocks - this minute, this hour - and resets the count at each boundary. It is simple, but a client can send a full allowance just before a boundary and another just after, briefly reaching twice the intended rate.
A sliding window counts requests over the most recent full window at every moment (either from a log of timestamps or by weighting the previous window’s count), so there is no boundary to exploit and no reset to wait for. A sustained rate above the limit is throttled continuously.
A token bucket holds up to a set number of tokens and refills at a steady rate. Each request spends a token, so after a quiet spell a client can send a burst up to the bucket size, but its long-run average can never exceed the refill rate. Many API gateways use it for exactly that reason. Check your provider’s documentation to see which approach it uses; the response headers often show the remaining allowance and reset time.
Staying under a limit
- Retry 429 responses with exponential backoff and jitter, and honour any Retry-After header.
- Cache responses that do not change often instead of fetching them for every user.
- Use batch or bulk endpoints where the API offers them, so one request carries many items.
- Queue background work and drain it at a fixed rate a little under the limit.
- Leave headroom - aim for 70-80% of a limit at peak, not 100% on average.
Formula
Allowed rate
limit ÷ window length (seconds)
Then × 60, × 3,600 or × 86,400 for per-minute, per-hour and per-day.
Current usage
current rate × window ÷ limit × 100%
Time until limit (fixed window)
limit ÷ current rate
Only when the rate × window exceeds the limit.
Limit needed
users × requests per user (in the same window)
Allowance per user
limit ÷ users
Token bucket empties after
burst ÷ (current rate − refill rate)
Worked examples
1,000 requests an hour, 50 users
The limit is 0.28 requests a second, 16.7 a minute or 24,000 a day. Sending 20 a minute is 1,200 an hour - 20% over - so the limit is hit after 3,000 seconds (50 minutes). Fifty users making 30 requests an hour each need 1,500 an hour; shared evenly, each gets 20.
10 a second with a burst of 100
Sending 30 requests a second hits a fixed-window limit a third of a second in. A token bucket holding 100 drains at 30 − 10 = 20 a second, so the spike survives for 5 seconds before requests are refused.
Frequently asked questions
How do I convert requests per minute to requests per second?
Divide by 60. A limit of 600 requests per minute averages 10 per second - though with a fixed window the whole 600 could legally arrive in the first second of the minute.
Why do I get 429 errors when my average is under the limit?
Averages hide bursts. If requests cluster - at the top of the hour, on page load, when a queue flushes - you can exceed the limit for a moment while the hourly average looks fine. Spread requests out or use a client-side throttle.
What is burst size?
In a token-bucket limiter, the bucket capacity: the most requests that can go through at once after a quiet period. The refill rate still caps the long-run average.
Is the per-user allowance enforced by the API?
Only if the API limits per user. If all your users share one API key, the allowance shown is just the limit divided evenly - a single heavy user can still use more than their share unless you enforce per-user limits yourself.
Is anything sent to a server?
No. You enter numbers only, and the calculation runs in your browser.