Exchange API rate limits: budget for the recovery burst

Exchange API rate limits constrain requests by rules such as IP address, account, endpoint, request weight and time window. After a limit response, follow the provider's retry instructions, reduce coordinated request load and preserve capacity for account recovery. Creating another API key does not reliably create another allowance. A delayed order response still needs reconciliation before any new submission.

A dashboard refresh looks harmless. So does a balance poll. Add several bots and a reconnecting stream, and the requests can compete for the same exchange allowance. The failure often appears at the worst time: the application needs more account reads to explain what happened, but its ordinary polling has already consumed the budget.

This guide treats rate limiting as a workload and recovery problem. The worked budget is fictional. It is not a statement of any exchange's current numerical allowance or a claim about KLINEO's internal scheduler.

Start with the scope of the limit

“Requests per second” describes only one possible rule. A venue may charge different weights for different endpoints, track an account's orders separately from public data requests, and apply more than one time window simultaneously. Staying below a long-window average does not guarantee that a short burst is permitted.

Binance Spot's WebSocket API documentation describes weighted request limits shared by IP and provides retry information when limits are exceeded. Bybit separately documents HTTP IP limits and per-UID, per-endpoint API limits, with response headers for the endpoint allowance. Those are different scopes to monitor, not interchangeable numbers. Binance WebSocket API limits, Bybit rate-limit rules.

KuCoin Classic documents resource pools and response headers for total quota, remaining quota and reset timing. Account tier and endpoint rules can affect the applicable allowance. Read the current documentation for the actual account and API family. KuCoin Classic rate limits.

A new key can still share the constrained IP or account. Do not rotate credentials or spread traffic across addresses to evade a provider's limits. Investigate the actual workload and use supported capacity arrangements.

Build a budget in weighted units

Assume an invented API allows 1,200 weighted units per 60-second window. Ordinary work consists of the following requests. These weights and counts are educational inputs, not copied venue rules.

The average ordinary load is 420 ÷ 60 = 7 units per second. That leaves 780 units in the fictional minute window, but it does not prove a 780-unit burst is acceptable under every other constraint.

Now suppose a stream gap triggers 160 recovery queries at weight 5. Recovery requires 800 units. If all ordinary work continues in the same window, the total becomes 420 + 800 = 1,220. That exceeds the invented 1,200-unit limit by 20 even though normal operation used only 35% of the allowance.

The lesson is about recovery demand, not the chosen utilization percentage. A system can appear quiet until a failure causes it to poll every instrument and account at once. Budget for the work needed to restore trustworthy state, including requests that failed or produced incomplete evidence when the provider's accounting rules charge them.

For a hosted service, the operator manages the shared workload. A reader should not assume they can tune backend polling from a browser refresh interval. Report repeated limit errors with the venue, product, environment and time through the KLINEO contact page; leave secrets and signed request strings out of the report.

Average load can conceal synchronized bursts

Imagine six processes each making one allowed-looking poll every second. If they all start on the same clock boundary, their requests arrive together. A limiter shared by the account or IP sees the combined burst, not six independent personal budgets.

The same issue appears after an outage. Ten disconnected clients can all reconnect, authenticate, subscribe and request a snapshot at once. A retry delay that is identical in every process can synchronize the next burst too.

A coordinated design uses the provider's rules as the authority, spreads optional work where appropriate and avoids duplicate requests for data that can be safely shared. Bounded backoff and varied retry timing can reduce synchronized retries, but they do not override an explicit provider retry time or make an otherwise forbidden load acceptable.

Market data and private account state also deserve different handling. Sharing a public ticker snapshot can reduce redundant requests. Sharing private account responses between unrelated users would create a privacy problem. Any caching or coalescing must preserve account and authorization boundaries.

The WebSocket recovery guide explains how a stream gap can create precisely the snapshot workload that a quiet-period average misses.

What should happen after a limit response?

First identify what was limited. Save the redacted provider code, endpoint family, observation time and available quota or reset information. An IP-level restriction can have a different effect from an account's order limit. Avoid collapsing both into “bad credentials.”

Then stop the retry storm. Follow the current provider instruction about waiting, reducing traffic or ending sessions. A generic exponential delay is not a substitute for an explicit ban expiry or retry boundary. Meanwhile, surface degraded state so that old balances or order rows are not mistaken for fresh observations.

Decide which work is necessary to understand existing exposure and which can wait. Optional screen refreshes should not compete indiscriminately with recovery. This is a scheduling principle, not a promise that cancellation or protective actions bypass exchange limits. They may be constrained too.

Finally, restore operation gradually after the documented wait and verify the account state. A successful public ping establishes connectivity to that endpoint. It does not establish that private requests or order actions are available again. The connection-health checks separate these observations.

A rate limit does not always resolve an order's outcome

The operator needs to distinguish a documented rejection from an ambiguous transport failure. If an order submission times out, a later rate-limit error on a status query does not tell you whether the earlier order was accepted.

Do not create a fresh order identity merely to make progress. Preserve the original client identifier and exchange context, then recover its status when supported access is available. The timeout reconciliation procedure covers this boundary in detail.

Repeated invalid orders can also waste capacity and obscure a separate configuration error. An order that violates quantity steps or minimum notional will not become valid by retrying it faster. Resolve its inputs using the exchange order minimums worksheet.

Authentication failures deserve another branch. Repeatedly signing with the wrong clock, key or encoding can fill logs while leaving the cause unchanged. Use the timestamp and signature diagnostic rather than automatically retrying every error with the same policy.

Read the counters as evidence, with their scope attached

A useful record ties each observed counter to its source: which endpoint returned it, what account or IP scope it represents, which window it covers and when it was received. A header from one request is not necessarily a complete view of every limit affecting the application.

Do not infer that an absent header means zero usage or unlimited capacity. The provider may omit a field on some errors or use another reporting mechanism. Likewise, a request count stored by one process can miss traffic from another process sharing the same allowance.

For the fictional 1,200-unit example, the operator's review might preserve four numbers: ordinary demand 420, modeled recovery demand 800, combined demand 1,220, and the relevant limit 1,200. The resulting action is to redesign when and how recovery work occurs, then test the failure path. Merely noting average usage of 35% would miss the problem.

Use a supported testing environment to examine coordinated backoff, resubscription and recovery behavior. The testnet acceptance guide helps specify exactly what a run proves. Do not intentionally exhaust a Live account's capacity to reproduce an educational example.

Keep a maintenance trigger for the budget

A request budget changes when the application adds accounts, instruments, order paths or recovery steps. Provider endpoint weights and limits can change as well. A plan copied from a previous version therefore needs a review trigger.

Maintain a short workload inventory with normal cadence, burst behavior, documented weight, shared scope and recovery use. Keep current primary documentation beside it. Review it after adding a new consumer, changing hosting routes or seeing unexplained throttling.

The practical objective is not to operate as close as possible to a published ceiling. It is to preserve enough observable, supported capacity to understand the account when something goes wrong. Even a careful budget cannot guarantee exchange uptime, immediate cancellation or a bounded trading loss.

Editorial method: Prepared with AI assistance on 20 October 2026 using current official provider limit documentation. The 1,200-unit allowance, request weights and workloads are original hypothetical inputs; all arithmetic was independently checked. No provider load test, customer telemetry or KLINEO scheduler performance measurement is claimed.