API Rate Limit Calculator
A free rate limit calculator for sizing an API throttle you can actually defend. Enter the capacity you can serve, the share one client may take and the burst you will tolerate, and get a per-second rate, a per-window quota, a token bucket size and a Retry-After value.
Rate Limit Calculator
Describe your normal traffic and the calculator returns a starting-point throttle. Everything runs in your browser.
What each number means
# token bucket rate = 10 req/s burst = 100 tokens # fixed window limit = 600 per minute # response when exceeded status = 429 Too Many Requests Retry-After: 1
An API rate limit is the ceiling you put on how often a single client may call your service. It protects the slowest thing behind your endpoint, keeps one noisy integration from degrading everyone else, and turns an outage into a throttle. The hard part is never the mechanism, it is choosing a number you can justify.
Why you need one
When to reach for it
How to size a rate limit
- 1. Measure real capacity. Load test the endpoint until latency degrades, and use the rate just below that point, not the theoretical maximum.
- 2. Decide one client’s share. Five percent is a reasonable default for a public API; raise it for a small number of trusted partners.
- 3. Pick a burst you can absorb. Set the tolerance from what your slowest dependency survives, and the bucket size follows.
- 4. Choose the window. Per minute reads well in documentation; per second enforces more smoothly. The calculator shows both.
- 5. Roll out in monitoring mode. Log what would have been throttled for a week, fix the false positives, then enforce.
Rate limiting strategies explained
Every gateway implements one of a handful of algorithms. They differ mostly in how they handle a burst.
Key features
- Turn backend capacity and a client share into a defensible per-second rate
- Per-second, per-minute, per-hour and per-day window quotas
- Token bucket capacity derived from the burst you can absorb
- A Retry-After value to send with every 429
- A copyable config snippet for your gateway
- Runs entirely in your browser, nothing is sent to a server
Why rate limits fail in production
Most rate limits fail for one of three reasons. The limit was picked as a round number rather than measured, so it either throttles legitimate traffic or never engages. The window was fixed, so a client that paces itself to the documented limit still delivers double the rate across a boundary and takes down the service anyway. Or the limit was applied per IP, so an office behind one NAT gateway is throttled as if it were a single abusive client.
The fix for all three is the same: measure the capacity you are actually protecting, prefer a token bucket or sliding window over a fixed one, key the limit on an account rather than an address where you can, and always answer with 429 plus Retry-After so clients can back off correctly instead of hammering you harder.
Frequently asked questions
How do I choose a starting rate limit?⌄
Start from the resource you are protecting, not from a round number. Measure what your backend serves comfortably, decide what share of that a single client may take, and let the calculator turn those two numbers into a per-second rate. Ship it in monitoring mode first, watch how many real clients would have been throttled, then enforce.
What is the difference between a fixed window and a token bucket?⌄
A fixed window counts requests in discrete blocks, so a client can send a full window at the end of one block and another full window at the start of the next, briefly doubling your load. A token bucket refills continuously and caps the burst at the bucket size, which maps far more closely to real traffic. The calculator gives you both numbers so you can compare.
What should I send when a client is throttled?⌄
Return 429 Too Many Requests, not a generic 500 or 403. Include a Retry-After header with the number of seconds to wait, and expose the limit, the remaining allowance and the reset time in RateLimit headers so a well-behaved client can pace itself rather than retry blindly.
Should I rate limit per IP or per API key?⌄
Per API key or per account whenever you have one: it survives NAT, mobile networks and shared offices, where thousands of users can appear behind a single IP. Fall back to IP for unauthenticated endpoints, and keep that limit looser than your authenticated one to avoid blocking whole offices.
Does the burst allowance let clients exceed my capacity?⌄
Briefly, yes, and that is the point. The bucket size is the burst you have decided you can absorb, so set it from what your slowest dependency tolerates rather than from what feels generous. If a burst of that size would take down a database, lower the burst tolerance until the bucket shrinks to a size you can serve.