Rate Limit Calculator

What is a rate limit?

A rate limit is a rule set by an API provider that caps how many requests a client may make in a given time window. A typical limit reads like 100 requests per minute, 1000 requests per hour, or 10 requests per second, and it exists to protect the provider's servers from overload, to keep costs predictable, and to ensure fair access when thousands of clients share the same service. When you exceed a limit, the API answers with an error, usually status code 429, and often tells you how long to wait before retrying, and ignoring that signal risks longer blocks or, in severe cases, suspension of your access. Understanding a limit in every time unit, and knowing the safe gap between requests, is therefore a basic skill for anyone who integrates with an API.

Rate limits come in several shapes, and the shape changes how you should code against them. A fixed window limit counts requests in blocks of time, such as each calendar minute, and resets abruptly at the boundary, which can allow a burst of twice the limit straddling the boundary. A sliding window limit counts the last sixty seconds continuously, which smooths bursts but is harder to reason about. A token bucket limit refills tokens gradually and allows short bursts up to a bucket size, which suits spiky traffic. A leaky bucket limit smooths output to a steady rate. This calculator works with the headline numbers, the limit and the window, which are what providers publish, and converts them into the equivalent rates that help you plan, regardless of the exact enforcement mechanism underneath.

How the calculator works

Enter the published limit and the window in seconds, and the calculator derives three equivalent rates and one practical delay. The per-second rate is the limit divided by the window, the per-minute rate is sixty times that, and the per-hour rate is thirty-six hundred times that, each rounded to two decimal places. The safe delay is the window in milliseconds divided by the limit, which is the average gap between requests if you spread them evenly across the window. For a limit of 100 requests per minute, the per-second rate is 1.67, and the safe delay is 600 milliseconds, meaning that spacing requests six tenths of a second apart keeps you inside the limit indefinitely, while firing all one hundred at once and then waiting is riskier under sliding window and burst rules.

The gauge gives an at-a-glance sense of intensity: it fills in proportion to the per-second rate, capped at one hundred percent, so a limit of 60 requests per second fills it completely while a limit of 100 per hour barely moves it. The gauge is a visual aid, not a precise instrument, and the numbers in the result are what you should code against. Copy the result into your integration notes or your code comments, so the next developer who touches the integration knows the intended pacing without hunting through provider documentation. The history keeps your recent conversions, which is handy when you are comparing several APIs or several pricing tiers side by side.

Converting limits between time windows

Conversion is simple arithmetic, but it is easy to get wrong under pressure, especially when providers mix units. A limit of 10 requests per second equals 600 per minute and 36,000 per hour, while a limit of 5,000 per day equals about 3.47 per minute, which reveals that a seemingly generous daily allowance can be painfully slow for interactive use. Always convert to the unit that matches your traffic pattern: if your application makes requests in response to user clicks, per-second thinking helps, because bursts happen in seconds; if it runs a nightly batch job, per-hour thinking helps, because the job's total duration is what matters. When a provider publishes multiple limits, such as 100 per minute and 10,000 per day, both apply simultaneously, and you must respect the tighter one for your pattern, which is usually the shorter window for bursts and the longer window for sustained load.

Watch out for per-user versus per-key versus per-IP limits, which are often published side by side and easily confused. A limit of 100 requests per minute per user is far more generous in aggregate than 100 per minute per API key, because each user gets their own allowance, while a per-key limit is shared across all your users. Similarly, some providers limit by endpoint, so a cheap endpoint and an expensive endpoint have different allowances, and a single global conversion can mislead you. Read the provider's documentation for the scope of each limit, and calculate separately for each scope that matters to your integration, rather than assuming one number covers everything.

Designing code that respects limits

The safest client spreads requests evenly, retries with backoff, and never hammers an endpoint that has just returned a 429 error. A simple approach is to pace requests with the safe delay from this calculator, adding a small safety margin, such as ten percent, to account for clock differences and for other processes sharing the same key. A more robust approach is a token bucket or a queue in your own code, which smooths bursts automatically and lets you prioritise important requests when the budget runs low. Either way, treat the published limit as a ceiling, not a target: running at ninety percent of a limit is comfortable, while running at one hundred percent invites edge cases, such as retries and clock skew, to push you over.

Retries deserve special care. When a request fails with a 429, the provider usually includes a Retry-After header telling you how many seconds to wait, and respecting it is both polite and practical, because retrying immediately only extends the block. Use exponential backoff, where each retry waits twice as long as the previous one, with a little random jitter so that many clients do not all retry at the same instant, a phenomenon known as the thundering herd. Cap the number of retries, log every 429 you receive, and alert if the rate of 429s rises, because a rising 429 rate usually means your traffic has grown past the limit and you need a higher tier, a cache, or a redesign, not more aggressive retries.

Caching, batching, and other ways to need fewer requests

The best way to survive a strict rate limit is to make fewer requests in the first place. Caching is the biggest win: if the same data is requested repeatedly, store it locally for a sensible time and serve repeats from the cache, which can cut request volume by ninety percent or more for read-heavy workloads. Batching is the second win: many APIs offer bulk endpoints that return fifty or a hundred records in one call, replacing fifty or a hundred individual calls. Webhooks invert the pattern entirely, letting the provider push updates to you instead of you polling for them, which eliminates polling traffic altogether. Conditional requests, using headers that ask the server to return data only if it has changed, save bandwidth and sometimes count differently against limits, so check the provider's rules.

Pagination is another place where request counts explode unnoticed. Fetching ten thousand records at fifty per page costs two hundred requests, while fetching them at five hundred per page, if the API allows it, costs twenty, so always request the largest page size the API supports. Similarly, avoid polling loops that check for changes every second when the data changes hourly, and prefer a schedule that matches the data's actual freshness. Each of these techniques reduces your effective rate, which is the rate that matters, and they often let a free tier serve a workload that seemed to require a paid tier.

Common rate-limit mistakes

The most common mistake is treating a per-minute limit as a per-second allowance, firing a hundred requests in the first second of a 100-per-minute limit and then being surprised by 429 errors. The second is ignoring the Retry-After header and retrying immediately, which turns a short pause into a long block. The third is sharing one API key across many services or environments, so development, staging, and production compete for the same allowance and production suffers. The fourth is hard-coding limits that later change when the provider updates a tier, so read limits from configuration or from response headers where the provider supplies them, rather than scattering magic numbers through code. The fifth is forgetting that errors and retries also consume budget, so a system that retries aggressively can exceed a limit it would otherwise respect.

• Convert every limit to the unit that matches your traffic pattern before coding.
• Space requests evenly at the safe delay, with a ten percent safety margin.
• Respect Retry-After and use exponential backoff with jitter.
• Cache aggressively, batch requests, and use the largest page size available.
• Never share one key across environments, and never treat a limit as a target.

A rate limit is not an obstacle to work around but a contract to design within. Convert it, pace to it, cache around it, and your integrations will stay fast, polite, and unblocked, even as your traffic grows.