Crypto Trading API Limits and Execution Latency Explained

Imagine a bot sending a 0.20 BTC buy order. Its screen stops responding. A second buy button appears, and the bot sends another 0.20 BTC. If the first order already filled, a connection problem has become a position twice the intended size. Improving the strategy’s entry signal would not fix that failure. The missing ingredient is a reliable record of the first instruction.

An API is the exchange’s connection for software to read markets and manage orders. For a futures trader, the important questions are practical: did the order reach the venue, did any quantity trade, is the remainder still live, and can an unwanted order be canceled? A fast price feed answers none of those account questions by itself.

Keep three records distinct. An intention is what the strategy wanted to do. An order is what the venue accepted or rejected. An execution is an actual fill, with a quantity and price. One intention can produce several orders, and one order can fill several times. Counting every message as another trade corrupts exposure even when every message is delivered correctly.

The rest of this guide follows those distinctions through rate limits, time measurements and recovery. It is written for someone selecting a bot or checking its behavior, as well as someone building one. You should be able to ask a provider how it handles these situations without having to read its entire codebase.

A request limit can count calls, weighted work, order submissions or active connections. They are different units. Binance’s USDⓈ-M order-book endpoint, GET /fapi/v1/depth, weights a snapshot according to its depth parameter. A request for 50 levels costs 2 weight units; 100 costs 5; 500 costs 10; and 1,000 costs 20. Omitting the limit selects the documented default of 500.

For a constructed workload of one snapshot every second, there are 60 calls per minute. Asking for 500 levels therefore consumes 600 weight units per minute. Asking for 50 levels consumes 120. The request count is identical; the weighted load is five times larger. These are calculated workloads, not statements about the allowance available to a particular account.

Scaling the same polling loop to ten symbols produces 600 calls and 6,000 weight units per minute at 500 levels. That cost arrives before the bot queries positions, reads history or sends an order. A dashboard that unnecessarily refreshes deep snapshots can consume capacity that other software using the same constrained resource also needs.

Budget a workflow rather than a single button. The opening request may be followed by status checks, stop placement, amendments and eventually cancellation. If the provider advertises a maximum request rate, ask which of those operations it includes. A limit with no unit, time window or account scope is not enough to plan around.

For continuous quotes, streaming updates can avoid repeatedly downloading the same snapshot. A snapshot remains useful for initialization or repair. The improvement is not “WebSocket means unlimited”: it is selecting a suitable delivery method for information that changes continuously, while reserving explicit queries for the situations that need them.

Bybit applies a default HTTP ceiling of 600 requests in five seconds per IP alongside rolling limits by user ID and endpoint. Use the endpoint limit and remaining allowance in its response headers when pacing that specific kind of call.

Reserve local capacity for reconciliation and risk-reducing actions before fresh entries or optional polling. Creating another API key or buying faster hardware does not necessarily create another allowance; a local priority queue cannot override the remote limit.

Contain retries before they consume the recovery budget

Ten workers retrying ten times create a hundred extra requests. Coordinate a bounded retry schedule and stop after explicit throttling. Bybit’s IP-frequency 403 calls for terminating HTTP sessions and waiting at least ten minutes; Binance distinguishes throttling from an unknown order outcome. The latter requires investigating the order, not resubmitting it blindly.

Bybit explicitly describes its order-placement response as asynchronous: acceptance is followed by order-status confirmation through the private stream. That distinction matters when evaluating a vendor’s “20 ms execution” claim. Twenty milliseconds to receive an order ID is not twenty milliseconds to obtain the requested quantity at a known price.

There are several useful clocks. Signal-to-send includes the bot’s own decision and queuing delay. Send-to-acknowledgement measures how long the submitting client waits for the acceptance response. Send-to-first-fill notification records when that client first learns that some quantity traded. Send-to-complete-fill notification ends only when the full requested quantity is reported as filled.

For a limit order, waiting for a matching counterparty can dominate the final interval. A long time to complete is not automatically a slow API. Conversely, a near-instant acknowledgement can be followed by a rejection, cancellation or an order that remains open. Compare like-for-like order instructions and quantities before attributing the difference to infrastructure.

The following invented timestamps are all readings from the same client clock. They illustrate interval accounting, not a measured result from Bybit or any other venue. The order is sent at 0 ms, acknowledged at 40 ms, first fill notification arrives at 95 ms, and the final fill notification arrives at 180 ms.

The same accounting applies to a network round trip: it already contains an outward and return path. Adding response delivery to a measurement that already ends on receipt would count that delivery twice. Define the start and end of each interval before combining it with another.

Real events need not arrive in this example’s order. A fill notification may reach the client before the acknowledgement on another connection. Preserve the actual timestamps and event meanings rather than forcing them into an expected sequence. For before-and-after performance comparisons, choose one precisely defined interval and retain that definition across both samples.

Binance’s futures documentation identifies a particular 503 response whose execution outcome is unknown, rather than failed. It advises checking order updates or querying the order before duplicating the submission. Other 503 messages describe failure. The HTTP status alone therefore does not tell the bot whether it is safe to create another opening order.

Return to the proposed 0.20 BTC entry. If the reply disappears, reserve that pending intention locally while investigating. Do not let a second strategy cycle treat the account as empty and repeat the full request. Otherwise, even a correct retry policy inside one function can be undermined by another part of the bot starting the same trade again.

A usable recovery record includes the market, side, requested quantity, account, submission time and a persistent client reference. Bybit calls its user-defined reference orderLinkId and documents uniqueness rules. Keep that reference attached to the original intention. It helps locate the request; it should not be presented as a universal guarantee that every exchange treats a repeated submission as the same order.

Reconciliation means matching that local record with the venue’s order and fill records. If the order exists, follow its actual state. If there is a documented definitive rejection, the strategy can decide whether a fresh order is still wanted. If the evidence remains inconclusive, the unresolved quantity stays unresolved; an empty response from one lookup is not an instruction to assume zero exposure.

Suppose investigation finds 0.08 BTC filled and 0.12 BTC still resting. Sending another 0.20 BTC would not “finish” the first request. If both remaining orders subsequently filled, the total would be 0.40 BTC. The desired next action could be keeping the existing remainder, canceling it, or changing the intended exposure. That decision depends on the strategy’s current objective, not the timeout message.

A restart should preserve unresolved intentions too. If the bot forgets its pending requests when its process restarts, it can reproduce the same duplication problem after every crash. Durable order references and a reconciliation step before new entries are more valuable here than shaving a few milliseconds from normal submissions.

Cancellation targets the quantity that has not yet executed. It cannot reverse a completed fill. A bot must therefore distinguish “cancel request sent” from “remaining order canceled,” and both from “position closed.” These distinctions become especially important when a price moves through the order while the cancel request is in flight.

Bybit documents a concrete race: two messages with Filled status can arrive when execution and cancellation coincide. One reports the fill; the other reports that cancellation failed because execution already occurred. Treating those status messages as two separate trades would double-count exposure. Its execution stream supplies execution IDs, prices and quantities for tracking actual fills.

Consider an order for 1 ETH. It fills 0.4 ETH, then another 0.3 ETH before cancellation of the final 0.3 ETH is confirmed. The result is a 0.7 ETH position and no live remainder. A screen showing “canceled” can be accurate about the remainder while the account still holds that 0.7 ETH. Cancellation did not restore the account to its pre-order state.

Use both an order-level view and a fill-level view. The former answers whether something can still execute; the latter explains the position already created. Replayed events should not add the same execution twice. A cumulative filled-quantity field should replace the previous cumulative figure, not be added to it as though every update were a new fill.

After a reconnect, fetch the missed fills and rebuild the order book and current position before the strategy resumes. Incoming messages alone will not repair the gap left during the interruption.

Bybit’s public order-book feed begins with a snapshot and then sends changes. Its documentation says a new snapshot replaces the local book; a zero quantity in a change removes that price level. Applying those rules incorrectly can leave nonexistent liquidity on screen. The visible book may look deep precisely because deleted levels were never removed.

Public and private recovery solve different problems. Rebuilding bids and asks tells the bot what is currently quoted. Reviewing its own recent executions and open orders tells it what it owns and what might still trade. Neither reconstruction substitutes for the other. A healthy market feed cannot confirm that a canceled entry actually stopped.

Define a pause condition for information that the strategy requires. A strategy relying on depth should not open new exposure from a book it knows is incomplete. A strategy with uncertain account fills should not assume a clean starting position. Recovery should restore the missing evidence and reconcile it, rather than merely turn a connection indicator green.

Start with the consequence the delay has for your strategy. A bot that adjusts one hedge after a signal has different needs from one that constantly replaces quotes. For the first, a missed or duplicated hedge may dominate. For the second, the age of resting quotes and the ability to cancel during bursts matter. A universal speed threshold would hide those differences.

Collect distributions rather than only the fastest sample. A median describes the middle observation; a high percentile describes slower observations near the tail. Report the sample count, period, location and measured interval. A sample taken while the account is idle does not describe a bot simultaneously tracking dozens of markets and issuing amendments.

For example, suppose 95 of 100 acknowledgements take 40 ms and five take 800 ms. The mean is 78 ms, while the slowest five orders each wait 800 ms. A single average obscures the very delays a trader might care about during a burst. Reporting that sample honestly requires both the normal behavior and the tail, without pretending that 100 observations establish a permanent service guarantee.

For a 0.5 BTC buy evaluated at $60,000 and filled at an average $60,030, adverse execution costs $15 before fees. Compare that result with the timing log: liquidity changes, spread and order instructions can also explain part of the difference.

A faster server is useful only when it improves the bottleneck that matters. It cannot make a passive price immediately match, remove an exchange throttle or repair a bot that double-counts fills. Test changes against the same workload and definition of success. Otherwise, an attractive speed chart can reward software that reports acceptance quickly but discovers its actual exposure late.

• Missing submission reply: look up the original order identifier before resending.
• Duplicate fill event: update executed quantity once.
• Partial fill followed by cancellation: preserve the filled position and cancel only the remainder.
• Reconnect: rebuild the account state before sending new exposure.
• Rate limit: pause optional requests while preserving capacity for essential order checks.

Exercise those paths with replayable events, then the venue’s test environment. Replay tests answer state-handling questions; a sandbox can check supported requests. Neither establishes live liquidity.

When choosing a bot, ask it to show one recovery trace from original intention to final quantity. Give it only the permissions the workflow needs and retain a manual account-access route. Revoking a key does not unwind positions already created.