Example 1
- limit 60
- unit per minute
- window 15 min
900
How many requests in the window at 60 per minute and 15 min? 900. Average RPM times the window, not a token bucket.
API Rate Limit Calculator
Type a limit, a unit, and a window. 60 per minute and 15 min give 900. 10 per second and 1 min give 600. 3600 per hour and 60 min give 3600. Average pace, not a token bucket.
Average RPM times the window, not a token bucket. Backoff after 429 lives on exponential backoff.
Results
Enter data and click Calculate.
How it works
The API Rate Limit Calculator in this calculator counts requests in a window from average RPM. 60 per minute and 15 min give 900. 10 per second and 1 min give 600. 3600 per hour and 60 min give 3600. That is an average, not a token bucket and not Retry-After.
The limit field is a number. The rate-limit-unit is min, sec, or hour. The window is in minutes. From min, RPM stays as typed. From sec the calculator multiplies by 60. From hour it divides by 60. Then RPM times the window.
900 is 60 times 15. 600 is 10 times 60 times 1. 3600 is 3600 divided by 60, then times 60. Another unit at the same 60 changes the result. The calculator does not read a 429 header.
Exponential backoff next door times the pause after an error. Cost per request multiplies a price by volume. Here the average pace stays: 60 and 15 min stay 900 requests in the window.
Type 60, pick per minute, window 15, then Calculate. A comma in 60.5 parses. Zero in the limit or the window is a field error, not a bucket. An average sketch, not a live API.
60 per minute and 15 min give 900. 10 per second and 1 min give 600. 3600 per hour and 60 min give 3600. Another window at 60 changes 900.
Formula
requests in window = RPM × window (min). RPM = limit (min), limit × 60 (sec), or limit / 60 (hour).
How to use
- Type the limit, for example 60.
- Pick per minute. Type window 15.
- Click Calculate. The result is 900 requests in the window.
- 10 per second and 1 min give 600. 3600 per hour and 60 min give 3600.
- Average RPM times the window, not a token bucket.
60 per minute and 15 min = 900
Average RPM times the window. 60 per minute and 15 min give 900. Not a token bucket.
- Rate Limit
- The typed limit. 60 per minute at window 15 leaves 900.
- window
- Minutes in the window field. 15 at 60 per minute gives 900 requests.
- requests
- The count in the window. 10 per second and 1 min give 600 requests.
Examples
Example 2
- limit 10
- unit per second
- window 1 min
600
What about 10 per second and 1 min? 600. 10 × 60 RPM × 1.
Example 3
- limit 3600
- unit per hour
- window 60 min
3600
What about 3600 per hour and 60 min? 3600. An hour folded into RPM.
Related calculators
Common questions
How many requests at 60 per minute and 15 min?
900. 60 RPM times 15 minutes. An average, not a token bucket.
What about 10 per second and 1 min?
600. 10 × 60 is 600 RPM, times window 1.
What about 3600 per hour and 60 min?
3600. 3600 / 60 is 60 RPM, times 60 minutes.
Is 900 a token bucket?
No. The calculator multiplies average RPM by the window. A burst from a bucket does not land here.
Does the calculator read Retry-After?
No. You type the limit and the window. There is no live API.
What does the unit change?
min keeps RPM. sec multiplies by 60. hour divides by 60. Then times the window.
Does a comma in 60.5 work?
Yes. 60.5 and 60,5 parse the same way.
Where do I time backoff after 429?
On exponential backoff. Here the request count in the window stays.
Does zero in the window count?
No. Limit and window must be positive. This is not an empty token bucket.
Knowledge sources
The calculator counts bits, bytes or throughput from your numbers. Below are SI and bit definitions (NIST).
Page updated in 2026.
What rate limiting is
Rate limiting caps the number of requests a client (a user, IP address, or API key) can send within a given time window. It protects a backend from overload, distributes resources fairly across clients, and is a standard part of public APIs — exceeding the limit typically returns an HTTP 429 Too Many Requests response.
Algorithms: token bucket, sliding window
- Fixed window — the counter resets at the start of every window (e.g. every minute); simple, but allows a 2x burst right at the boundary between two windows.
- Sliding window — counts requests in the last N seconds regardless of clock boundaries; fairer, but needs more memory for history.
- Token bucket — a "bucket" fills with tokens at a steady rate; each request consumes a token. This allows short bursts up to the bucket size while keeping the average rate over time.
Formulas: RPS, RPM, interval
The calculator normalizes the given limit to RPM (requests per minute), then computes: RPS = RPM / 60, Requests in window = RPM × window length (min), Minimum interval = 60 / RPM seconds. This is the average rate — token-bucket and similar policies can allow short deviations above this average.
HTTP headers and status 429
A well-designed API tells the client its limit status through headers, e.g. X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and Retry-After on a 429 response — stating exactly how long to wait before retrying. Clients should respect these headers and use backoff (ideally with jitter), not blind retries.
Designing limits: burst vs sustained
- A "sustained" limit (average over a long window) protects the backend long-term but can be too rigid for natural traffic bursts (e.g. a page refresh firing several requests at once).
- Many APIs combine two limits: a short-term one (e.g. 10/s) for bursts and a long-term one (e.g. 10,000/day) for total resource usage.
- When setting a limit for your own API, base it on real client usage patterns, not just infrastructure capacity — an overly strict limit frustrates legitimate users.
Examples
- Gateway 1000 req / 15 min (typical public API) → RPM = 1000, RPS ≈ 16.67, min interval ≈ 0.06 s — clients need a queue, not blind retries.
- 5 req/s sustained, 1-min window → 300 in window, RPM = 300 — common webhook / partner-API ceiling.
- 10,000 req / hour (SaaS plan) → RPM ≈ 166.67, interval ≈ 0.36 s — calmer pacing; still honour Retry-After.