API rate limit calculator: budget weights and requests
Enter your API's limit, its window and what your program calls to see the share used per window, the headroom, the largest symbol count that fits and a backoff schedule. Every number is yours. Free, no sign-up required.
What is an API rate limit?
An API rate limit is the number of requests, or units of request cost, a server accepts from you in a window of time. Above it, the server refuses requests until the window moves on.
- Requests or weights: some APIs count each request as one; others charge a weight that depends on the endpoint and its parameters. Type a weight of 1 if each call counts once.
- HTTP 429: RFC 6585 defines 429 Too Many Requests for this case and says the response may carry a
Retry-Afterheader. It also says the standard does not define how a server identifies you or counts your requests, so read your API's own rules. - 429 against a ban: a 429 asks you to slow down. Some APIs escalate if you do not: Binance's REST document, read on 5 November 2026, says repeated violations bring an automated IP ban with HTTP 418. The Binance API rate limit guide has the details for that one API.
This page holds no table of exchange limits, because those go stale. The official pages under Sources are dated references: take your limit, window and weights from the current version.
How the budget is calculated
Each row turns into units per window, and the rows add up against the limit:
Units per cycle = weight × calls per cycle × symbols
Units per window = units per cycle × window ÷ cycle
Share used = units per window ÷ limit
Largest symbol count = (limit − units of the rows without a symbol count) ÷ units per window of one symbol, rounded down
Burst time = limit ÷ burst speed
A row with a symbol count scales with it; a row with that field empty, such as an account call, does not. The result is an average over the window. Real calls can bunch at the start of a cycle, a retry adds calls, and a sliding window counts differently from a fixed one, so headroom is a margin and not a promise. The burst time assumes an empty window at the start.
Worked example
Hypothetical example, not any exchange's figures: a limit of 1,000 units per 60 seconds and the calculator's default rows.
| Endpoint | Weight × calls × symbols | Cycle | Units per cycle | Units per window | Share of the limit |
|---|---|---|---|---|---|
| Order book | 5 × 1 × 4 | 5 s | 20 | 240 | 24% |
| Open orders | 6 × 1 × 4 | 10 s | 24 | 144 | 14.4% |
| Account | 10 × 1 | 30 s | 10 | 20 | 2% |
Used: 240 + 144 + 20 = 404 units, 40.4% of the limit. Headroom: 596. One symbol costs 5 × 12 + 6 × 6 = 96 units per window, so the largest symbol count is (1,000 − 20) ÷ 96 = 10.2, rounded down to 10.
A burst of 100 units per second uses up an empty window in 10 s. A separate order limit of 100 per 10 seconds, with 30 orders over 60 seconds, runs at 5 orders per window, 5% of that limit.
Exponential backoff with Retry-After
After a 429, wait as long as Retry-After says, then let the delay grow between retries so that you stop adding load.
Delay for retry n = minimum of (cap, base × factorn−1)
Each wait falls between the delay minus the jitter and the delay itself. Jitter spreads retries out, so that many clients do not come back in the same instant. The first wait is never shorter than the Retry-After you type; RFC 9110 says the header holds seconds or an HTTP date, so turn a date into seconds first.
| Retry | Computed delay | Wait | Total so far |
|---|---|---|---|
| 1 | 1 s | 5 s | 5 s |
| 2 | 2 s | 1.6 to 2 s | 6.6 to 7 s |
| 3 | 4 s | 3.2 to 4 s | 9.8 to 11 s |
| 4 | 8 s | 6.4 to 8 s | 16.2 to 19 s |
| 5 | 16 s | 12.8 to 16 s | 29 to 35 s |
| 6 | 30 s | 24 to 30 s | 53 to 65 s |
The table states a schedule, not a recommended setting. Retrying an order is a separate problem from retrying a read, because a blind retry can place it twice: see crypto exchange API integration.
API gateway rate limits: rate and burst
A gateway often sets a steady rate and a burst instead of a window. Amazon API Gateway's document describes a token bucket with a rate and a burst, 429 responses once both are exceeded, and limits applied on a best-effort basis. For this calculator, type the rate × the window as the limit: a hypothetical 10 requests per second over 60 seconds is 600. The bucket itself empties in burst ÷ (request speed − rate) seconds, so a bucket of 50 at 20 requests per second against a rate of 10 lasts 5 seconds.
Which values to enter
- Limit and window: from your API's current documents. Some APIs also return the used weight in response headers, which is the best check of your numbers.
- Rows: one per repeating call. Use cycle length in seconds and leave Symbols empty if the call does not repeat per symbol.
- Order limit: fill in all four fields if your API counts orders separately, or leave all four empty.
- Backoff: your own values. The defaults only show the arithmetic.
If the budget is too tight, make fewer calls: a WebSocket stream can replace polling, and the Bybit API guide shows one such setup. Do not spread traffic over extra keys, accounts or IP addresses to get around a limit. Exchange names on this page describe their documents only, and nothing here recommends one. For readers in Turkey, Article 99/A of Capital Markets Law No. 6362 treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized. Help with the integration itself is under exchange API integration.
Frequently asked questions
What is an API rate limit?
It is the number of requests, or units of request cost, a server accepts from you in a window of time. Above it the server refuses requests, usually with HTTP 429, until the window moves on.
How do I calculate requests per minute?
For each repeating call, take calls per cycle × 60 ÷ cycle length in seconds, then add the results. Divide by 60 for requests per second. If the API charges weights, multiply each call by its weight first.
How do I set an API rate limit?
If you run the API, pick a rate and a burst your backend can serve and enforce them at the gateway. If you call someone else's API, the limit is theirs, and you budget your own calls below it.
What is the difference between a 429 and a ban?
A 429 tells you to slow down for now. A ban blocks you for a period, and some APIs impose one when you keep sending after 429s. Read your API's rules, because the steps and durations differ.
What is exponential backoff?
Waiting longer after each failed try: the delay is the base times the factor to the power of the retry number minus one, up to a cap, usually with jitter. The calculator shows the schedule for your own values and recommends none.
Can I use several API keys to get a higher limit?
Do not use extra keys, accounts or IP addresses to get around a limit. It can break the exchange's rules and lead to a ban. Reduce calls or ask the exchange about the limits it offers.
Sources
- RFC 6585: Additional HTTP status codes, section 4, 429 Too Many Requests (opens in a new tab)
- RFC 9110: HTTP semantics, section 10.2.3, Retry-After (opens in a new tab)
- Amazon API Gateway: Throttle requests to your REST APIs (opens in a new tab)
- Binance Spot API documentation: REST API, limits (read 5 November 2026) (opens in a new tab)
- Bybit V5: Rate limit rules (read 5 November 2026) (opens in a new tab)
- Kraken: Spot REST rate limits (read 5 November 2026) (opens in a new tab)
- OKX API v5: Rate limits (read 5 November 2026) (opens in a new tab)
- Capital Markets Law No. 6362, consolidated text, Article 99/A (Turkish) (opens in a new tab)
This calculator is general information, not tax, legal or investment advice. Results depend on the values you enter; fees, margin rules and tax rules differ by exchange and country and change over time, so check the official source and ask a licensed adviser about your own situation. Sources, checks and corrections: see the editorial policy.
Related guides
Send a short project brief
The form or an email is enough. You do not need to share your rules yet.
- The exchange or platform you use
- What the software should do
- Your target timeline
- Project briefs and business inquiriesinfo@fincodelabs.com
- WhatsApp (messages only)+90 545 697 41 15 (opens in a new tab)