API Rate Limit Calculator

API rate limits are documented in a genuinely wide variety of conventions across different providers — some specify a limit per second, others per minute, others per hour or even per day — and this variety, while each individual convention is simple enough on its own, makes comparing rate limits across different providers or API endpoints surprisingly easy to get wrong without a consistent normalization step.

Converting any stated rate limit into requests per second, regardless of its originally documented time window, provides exactly this consistent basis for comparison — a limit of '1,000 requests per hour' and a limit of '20 requests per minute' look superficially quite different, but normalized to a per-second basis, they reveal their actual relative generosity clearly (1,000 per hour works out to about 0.278 requests per second, while 20 per minute works out to about 0.333 requests per second — the per-minute limit is actually somewhat more generous, a comparison that isn't at all obvious from the two differently-windowed figures as originally stated).

The calculator's stated limitation — assuming requests spread perfectly evenly across the stated window — deserves genuine attention, since real-world rate limiting implementations frequently behave differently from this idealized even-spacing assumption, and understanding the most common real algorithm (token bucket) clarifies why. A token-bucket rate limiter maintains a conceptual 'bucket' that accumulates tokens at a steady rate up to some maximum capacity, and each request consumes one token — critically, this means a client that hasn't made requests recently can accumulate a reserve of tokens and then make a genuine burst of requests in rapid succession (up to the bucket's capacity), well above the theoretical steady-state average rate, before being throttled back down to the sustained average rate once the accumulated token reserve is exhausted. This burst-tolerant behavior is quite different from a strict, perfectly even request-spacing model, and it's exactly why many real APIs can comfortably absorb a legitimate short burst of client activity (a user rapidly clicking through several actions, for instance) without immediately throttling, even though the API's documented rate limit, taken as a strict even-spacing average, would seem to suggest that burst should trigger throttling.

This distinction matters genuinely for designing request pacing in a batch job or bulk integration specifically. A naive implementation that fires requests as fast as possible until hitting a rate-limit error, then backs off, works reasonably well against a token-bucket limiter (since it can legitimately consume the burst allowance before settling into the steady-state rate), but performs poorly against a stricter fixed-window or sliding-window limiter that doesn't permit the same burst tolerance. Conversely, a very conservative implementation that paces requests strictly at the calculated steady-state per-second rate, never bursting even when a token-bucket limiter would permit it, leaves real throughput on the table against a burst-tolerant limiter, unnecessarily slowing down a batch job that could safely complete faster.

The genuinely practical approach for designing request pacing against an unfamiliar or undocumented rate-limiting algorithm is to start conservatively (well below the calculated theoretical steady-state rate), monitor actual API responses for rate-limit warnings or errors, and adjust pacing dynamically based on the API's real observed behavior — a more robust strategy than assuming any specific rate-limiting algorithm's behavior without direct confirmation from the provider's documentation or from careful observed testing against the actual live API.