Does this account for burst capacity or token-bucket algorithms?

No, it models a simple sustained rate: N requests evenly spread across the window. Many real APIs actually use a token-bucket or leaky-bucket limiter that allows short bursts above the sustained rate, so treat the numbers here as a safe, conservative baseline rather than the exact algorithm your API enforces.

How is 'time to send' calculated?

It divides your planned request count by the sustained requests-per-second rate, giving the minimum time needed if you sent requests continuously at exactly the limit with no bursts, retries, or backoff. Real-world time will usually be longer once you account for those.

What's the minimum delay between requests for?

It's 1000 divided by the requests-per-second rate, i.e. the largest fixed delay you could put between requests and still stay exactly at the limit over time. Spacing requests out by at least that much is a simple way to avoid tripping a rate limiter without needing a full token-bucket implementation.

API Rate Limit Calculator - Requests Per Second & Time to Send

Overview

Introduction

API docs usually state a rate limit as 'N requests per window', which isn't directly useful when you're deciding how fast a script can safely make calls.

This calculator converts that into a requests-per-second rate and a minimum delay between calls, plus an estimate of how long a batch of requests will take, entirely in your browser.

What Is API Rate Limit Calculator?

A small calculator that treats a stated rate limit as a sustained, evenly-spread rate and derives the practical numbers you need from it: per-second/minute/hour/day equivalents, minimum request spacing, and time-to-completion for a batch.

It's part of this site's API Tools collection and runs entirely client-side.

How API Rate Limit Calculator Works

The window length (in seconds) is derived from your chosen unit, then the limit is divided by that to get a requests-per-second rate.

That rate is then scaled up to minute/hour/day equivalents, inverted to get a minimum safe delay in milliseconds, and used to estimate how long your planned request count would take to send.

When To Use API Rate Limit Calculator

Use it when you're writing a script or integration against an API and need to know how long a full data sync or bulk import will realistically take under its rate limit.

It's also useful for sanity-checking whether a planned request volume fits comfortably within a documented limit before you build retry/backoff logic.

Often used alongside Webhook Tester.

Features

Advantages

Converts between per-second, per-minute, per-hour, and per-day framings in one step.
Gives a concrete minimum delay you can drop straight into a sleep/setTimeout call.

Limitations

Assumes an even, sustained rate; it doesn't model burst allowances, token buckets, or per-endpoint limits that differ from the overall account limit.
Doesn't account for network latency, retries, or backoff time, which will make a real batch take longer than the raw calculation suggests.

Examples

Converting a per-minute limit

Input

100 requests per 1 minute

Output

1.67 requests/sec, minimum delay 600ms

100 requests spread over 60 seconds is about 1.67 per second, so requests should be spaced at least 600ms apart to stay under the limit continuously.

Estimating time for a batch

Input

5,000 planned requests at 1.67 requests/sec

Output

≈ 50m 0s

5,000 divided by 1.67 requests/sec is about 3,000 seconds, or 50 minutes, of continuous sending at exactly the limit.

Best Practices & Notes

Best Practices

Treat the minimum delay as a floor, not a target; add some margin so occasional clock drift or retries don't tip you over the limit.
Check whether your API documents separate limits per endpoint or per API key; this calculator only models one flat limit at a time.
Re-run the batch estimate whenever the planned request count changes significantly, since it scales linearly with that number.

Developer Notes

All internal math is done in requests-per-second regardless of the input unit, so the conversions between minute/hour/day equivalents are exact multiplications rather than separate re-derivations, avoiding any rounding drift between the displayed numbers.

API Rate Limit Calculator Use Cases

Estimating how long a full data export or import will take against a documented API rate limit
Deciding on a safe delay between requests in a script before you've implemented a proper rate limiter
Converting a rate limit from one time unit to another to compare two APIs' limits directly

Common Mistakes

Treating the calculated minimum delay as a hard guarantee against 429 errors when the real API also enforces burst limits this tool doesn't model.
Forgetting that the time-to-send estimate excludes network latency and any retry/backoff delays, which add up over a large batch.

Tips

If your API's docs mention a separate burst allowance, budget extra headroom below the calculated minimum delay rather than sending exactly at it.

API Rate Limit Calculator