API Rate Limit Calculator
Project total API requests from a per-second rate.
Results update as you type.
How it works
An API rate limit calculator projects how many requests a steady per-second rate produces over a chosen window, and the equivalent per-minute rate. APIs are commonly governed by limits expressed per second, per minute, per day, or per month, and converting between these units is essential for staying under a quota, sizing a plan, or estimating the load a client will generate. This matters on both sides of an API. If you consume an API, projecting your request volume tells you whether your usage fits within a provider's daily or monthly allowance before you hit throttling or overage charges. If you operate one, the figures help you set limits that protect your infrastructure while accommodating legitimate traffic. Converting a burst rate into daily and per-minute totals makes an abstract limit concrete and easy to plan against. The calculation works because at a constant rate, total requests equal the rate multiplied by the elapsed time once units align. Multiplying requests per second by 3,600 gives requests per hour, and multiplying by the number of hours gives the window total; multiplying the per-second rate by 60 gives the per-minute figure. Real traffic is bursty rather than perfectly steady, so pair this baseline with headroom for peaks. Developers, platform engineers, and API product teams use a rate limit calculator to align usage with quotas.
total = requests per second × 3,600 × hours
A steady request rate multiplied by the number of seconds in the window gives the total count of requests. One hour holds 3,600 seconds, so multiplying the per-second rate by 3,600 and then by the number of hours yields the total over the period. The per-minute figure comes from multiplying the per-second rate by 60. The approach works because at a constant rate, total volume is simply rate times elapsed time in matching units.
Source:Standard rate arithmetic
We review all our tools from time to time to ensure accuracy.
Worked example
How to use this calculator
- 1
Enter your values
Enter requests per second and time window.
- 2
Adjust the options
Fine-tune any options to match your situation.
- 3
Read your result
Total requests updates instantly as you type — no button to press.
Frequently asked questions
How do I convert between rate limit units?
Multiply or divide by the number of seconds in the target period. Requests per second times 60 gives per minute, times 3,600 gives per hour, and times 86,400 gives per day. To go the other way, divide. This calculator handles the arithmetic so you can check whether a per-second client rate fits inside a provider's daily or monthly quota, which are often expressed in entirely different units.
Should I plan for average or peak rate?
Both. Average rate tells you whether your total volume fits a daily or monthly quota, while peak rate determines whether you trip a per-second or per-minute burst limit during busy moments. Real traffic clusters, so a client averaging a modest rate can still exceed a per-second cap in a spike. Size against your realistic peak for burst limits and against your average for long-window quotas, leaving headroom for both.
What happens when I exceed a rate limit?
Most APIs respond with an error, commonly HTTP status 429 Too Many Requests, and reject the excess calls until the window resets. Some queue or throttle instead, and others charge overage fees. Well-behaved clients respect a Retry-After header and back off. Projecting your volume with this calculator helps you stay under the limit, or request a higher tier in advance, rather than discovering the ceiling through failed requests in production.
Why express the limit per minute as well?
Different providers publish limits in different units, so having both a per-minute and a total figure lets you compare directly against whatever a given API states. Per-minute is a common window for burst limits, while the total over hours matches daily quotas. Seeing your rate in several units at once makes it easy to line up your projected usage with the specific limit format each provider chooses to enforce.
Does this assume a constant request rate?
Yes. The projection multiplies a steady rate by time, which gives an accurate total for uniform traffic but smooths over real-world bursts and idle periods. Actual clients send requests in clusters driven by user activity or batch jobs. Use the total for capacity and quota planning, but add a safety margin for peaks, since a burst can breach a short-window limit even when the long-run average sits comfortably within quota.