API Rate Limit Calculator
Understand how many API calls your rate limit allows over different windows — convert to RPS, RPM, and the minimum interval between requests (average rate, not a full token-bucket model).
Results
Enter data and click Calculate.
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.
FAQ — API rate limits
- What is rate limiting in a nutshell?
- Limiting the number of requests per unit of time for a given client — it protects the server and distributes resources fairly.
- How is token bucket different from a fixed window?
- A fixed window resets its counter at a clock boundary (allowing a burst right at the boundary between windows). Token bucket allows a controlled burst up to the bucket size while keeping the average rate over a longer period.
- What is a "burst", and how does it affect retries?
- A burst is a short spike above the average rate (e.g. a page refresh). Sustained limits protect over longer windows; burst limits allow brief peaks. After HTTP 429, honor Retry-After or use exponential backoff with jitter — blind retries deepen overload and burn the limit.
- How should a client react to a 429 response?
- Wait for the duration in the Retry-After header (if present) and retry with exponential backoff plus jitter — never retry blindly and immediately, as that deepens the overload.
- Should I rate limit per IP or per API key?
- It depends on the model — per API key is more precise for authorized clients, per IP protects against anonymous traffic but fails behind NAT (many users sharing one address).
- Does this calculator compute real burst limits?
- No — it only computes the average rate (RPM/RPS/interval) for client pacing. Token buckets may briefly exceed the average by the bucket size; on 429 use Retry-After / backoff.
- What limits do popular APIs use?
- Widely varied — from a few requests per second (paid AI APIs) to thousands per minute (large platforms). Always check the specific provider’s docs, since limits change with the pricing tier.
- How does window length affect the perceived limit?
- A shorter window (e.g. 1 second) forces more even traffic. A longer window (e.g. 1 day) gives more room for bursts but less protection against momentary overload.