API rate limit calculator
With a limit of 100 calls per minute, sending 350 takes 4 windows: three batches of 100 and one of 50, 60 seconds apart, at least 180 seconds in total. Plan imports, syncs or backfills that never trip the provider's limit. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Rate limit
- 100
- Desired requests
- 350
- Window seconds
- 60
- Windows needed
- 4
- Batch size
- 100
- Last batch size
- 50
- Full batches
- 3
Public and private APIs almost always publish a rate limit such as one hundred requests per minute or one thousand requests per hour.
How a rate limit turns into batches
A limit of 100 calls per 60-second window means the provider accepts at most 100 calls in any window of that length. When you need more, you cannot send everything at once. The safe plan is to send one full batch, wait until a whole window has passed, send the next batch and repeat until nothing is left. The number of windows is the total divided by the limit, rounded up: 350 calls at 100 per window need 4 windows, three full batches of 100 and a final batch of 50. The wait between batch starts equals the window length, here 60 seconds, and it drops to zero when one window is enough.
Timing the whole job and avoiding surprises
Because the first batch can start straight away, the shortest total time is the number of windows minus one, times the window length: 3 times 60 seconds, or 180 seconds for the example. Leave the window empty and 60 seconds is assumed. The plan is deliberately cautious for fixed windows and a solid first budget for token buckets that do not refill mid-burst. The calculator never contacts the service itself; it only sizes the schedule so your own program can pause between batches. Asking for zero calls returns zero windows and no delay, which is handy for a dry run.
How windows, batches, and delay keep you under the limit
A rate limit of R requests per window of length W seconds means that in any sliding or fixed window of W seconds the provider will accept at most R successful calls. When you need D total requests and D is larger than R, you cannot fire everything at once. The safe plan is to send at most R requests in the first window, wait until a full window has elapsed, send the next R, and repeat until the remainder is gone.
The number of windows required is the ceiling of D divided by R. If D is three hundred fifty and R is one hundred, you need four windows: three full batches of one hundred and a final batch of fifty. The delay between batch starts equals W when more than one window is required, and zero when a single window is enough.
Minimum elapsed time is then (windows minus one) times W, because the first batch can start at time zero and the last batch starts after the previous waits. This model matches the common fixed-window and token-bucket planning heuristics used in client libraries: it is intentionally conservative for fixed windows and a solid first budget for token buckets when you do not refill mid-burst.
FAQ
What delay should I wait between batches?
When a single window is enough, the delay is zero.
How many windows do I need for 350 calls with a limit of 100?
Four. Divide 350 by 100 and round up: three full batches of 100 and a final batch of 50. The last batch is smaller, so it never goes over the limit.
What is the shortest time the whole job can take?
The number of windows minus one, times the window length. With 4 windows of 60 seconds that is 180 seconds, because the first batch can start immediately and only the gaps add time.
Does the calculator make these calls for me?
No. It never contacts the service. It only sizes the schedule, so your own script or program sends one batch at a time and pauses for the suggested delay before the next one.
Does this plan also work for token-bucket limits?
Yes, as a cautious first budget, as long as the bucket does not refill in the middle of a burst. For fixed windows the plan is deliberately conservative, so you stay under the limit.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/api-rate-limit-calc \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"rate_limit":100,"desired_requests":350}'const res = await fetch("https://api.kit.forhosting.com/dev/api-rate-limit-calc", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"rate_limit": 100,
"desired_requests": 350
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/api-rate-limit-calc",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"rate_limit": 100,
"desired_requests": 350
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/api-rate-limit-calc", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"rate_limit":100,"desired_requests":350}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"rate_limit":100,"desired_requests":350}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/api-rate-limit-calc", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"rate_limit": 100,
"desired_requests": 350
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.api_rate_limit_calc",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Engineers who need to send more traffic than a single window allows must split the work into batches and wait between them so the provider does not return HTTP 429 or revoke credentials. This API rate limit budget calculator accepts the maximum requests per window, the total number of requests you plan to send, and an optional window length in seconds. It returns how many windows you need, the maximum batch size that never exceeds the limit, the size of the final partial batch, the delay to insert between batch starts, the minimum wall-clock time if you start the first batch immediately, and the equivalent maximum requests per second. Non-positive rate limits fail with invalid_input and are not billed.
How windows, batches, and delay keep you under the limit
The calculator does not call the remote API; it only sizes your schedule so your own client can sleep between batches.
Input contract, response fields, and validation rules
Zero desired requests returns zero windows and zero delay without error, which is useful for dry-run planners. POST a JSON body with rate_limit, a positive whole number of requests allowed per window; desired_requests, a non-negative whole number of calls you intend to make; and optional window_seconds, a positive finite length of that window in seconds that defaults to sixty when omitted. Each field may arrive as a JSON number or as a numeric string. Missing fields, non-finite values, fractional desired_requests, fractional rate_limit, and any rate_limit that is not strictly positive fail with invalid_input and a message that names the field. On success the body echoes rate_limit, desired_requests, and window_seconds, then returns windows_needed, batch_size (the maximum requests per full batch, equal to rate_limit when work remains), last_batch_size (the trailing partial batch, or a full batch when D divides evenly), full_batches (how many batches use the maximum size before the remainder), delay_between_batches_seconds, min_elapsed_seconds, max_requests_per_second as rate_limit divided by window_seconds, and a short formula string restating the ceiling rule. Example: rate_limit one hundred, desired_requests three hundred fifty, window_seconds sixty yields four windows, batch size one hundred, last batch fifty, delay sixty seconds, and minimum elapsed one hundred eighty seconds.
Where an API rate limit budget calculator earns its keep
Feeding that count plus the vendor rate limit into this calculator produces a sleep schedule you can drop into a worker loop without trial-and-error 429 storms. Product managers estimating how long a bulk export will take can convert a document count into wall-clock time before promising a customer a same-day window. Failed validation does not consume balance. Integration scripts that backfill webhooks, reindex search documents, or migrate tenants often know the total item count before they start. Observability and chaos tooling can assert that a synthetic load generator never exceeds max_requests_per_second derived from the published limit. Keep the schedule logic in your client; use this endpoint as the single source of truth for the arithmetic so mobile, edge workers, and CI jobs all plan the same way.
Integration use cases
Bulk migration and backfill jobs
Split a known request count into rate-limit-safe batches and sleep delay_between_batches_seconds between each batch start.
SLA and runbook estimates
Convert vendor rate limits into min_elapsed_seconds so on-call plans and customer ETAs match the real throttle.
Load-test and synthetic traffic caps
Derive max_requests_per_second from rate_limit and window_seconds before configuring generators that must not trip production guards.
Technical questions
How do I calculate how many windows I need for an API rate limit?
Send rate_limit (positive whole requests per window), desired_requests (total calls), and optional window_seconds (default 60). windows_needed is ceil(desired_requests / rate_limit).
What if the rate limit is zero or negative?
The task fails with invalid_input. A non-positive rate limit is not a valid budget and the call is not billed.
Does the calculator call my API or sleep for me?
No. It only returns the schedule numbers. Your client sends the batches and applies the delay.
What does the API rate limit calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.