Exchange API WebSocket recovery requires more than reconnecting a socket. Restore the correct subscriptions, verify data continuity under the venue's protocol, refresh account state where needed and reconcile orders affected by the observation gap. A new heartbeat proves that a connection is alive; it does not prove that missing market updates or private execution events have been recovered.
At 14:03:10 the price panel stops moving. Five seconds later it starts again. The reconnect indicator disappears, but the account has not necessarily returned to a known state. A market-data gap and an unseen order fill require different recovery work.
This guide follows those two lanes separately. It is for readers evaluating connection behavior and for operators designing a recovery record. It does not assert that KLINEO implements every protocol or recovery technique described.
A live socket can carry an incomplete picture
WebSockets provide ongoing messages over a connection. They do not, by themselves, guarantee that your application processed every event, retained it correctly or subscribed to the intended account and instrument after reconnecting.
A transport interruption is one cause of a gap. Other causes include a failed subscription, an expired authentication session, a slow consumer, a local process restart or a message rejected during parsing. Even without a visible disconnection, the displayed data can become stale.
Separate three observations: the last transport activity, the last relevant data event and the last verified state. A heartbeat received one second ago can coexist with an order book whose continuity has not been established since a restart. A trade feed can be active while private account authentication has failed.
The connection-health guide turns these into distinct checks. Avoid letting one green connection indicator stand in for all of them.
Market data: recover continuity, not just a recent price
Some market feeds send full snapshots; others send incremental changes that depend on an earlier state. Applying incremental messages to the wrong snapshot can produce a plausible-looking book that never existed at the exchange.
Binance Spot documents a local-order-book procedure using buffered depth updates, a REST snapshot and update identifiers. Its protocol explains which updates can be applied and when a detected gap requires rebuilding state. Follow the current venue-specific procedure rather than treating the next message as a complete replacement. Binance Spot local-order-book procedure.
Consider an invented incremental protocol in which every integer sequence must be covered. The local state is verified through sequence 100. A received event covers 101–103. The next event covers 107–109. In this constructed protocol, sequences 104, 105 and 106 are missing.
The newest event can contain a valid bid and ask. It still cannot explain the missing changes. Showing it as a fully verified book would confuse freshness with continuity. Recovery needs the protocol's supported snapshot and sequence procedure, not an invented interpolation between old and new prices.
This numerical example is generic. Real venues can use ranges, overlapping updates or product-specific sequence rules; do not copy its integer comparison directly into a Binance, futures or Bybit client.
Account data: determine what happened while observation was lost
A private stream carries account events such as order status or executions. Reconnecting does not establish that events emitted during the gap will all be replayed. The supported recovery path may require order, trade or position queries in addition to resubscribing.
Use the exact account, product and environment. A current balance is a useful observation, but it may not identify which order changed that balance. Open orders alone can miss a fully filled order. Positions alone can combine the effect of several trades.
Recover the original order identifiers and compare status, cumulative fills, relevant execution records and present exposure. Preserve uncertainty when the available evidence cannot establish a final state. The order timeout reconciliation article explains why a missing open-order row is insufficient evidence that nothing traded.
An event consumer must also distinguish a status notification from a new execution. Bybit's private-order documentation warns that a cancellation race can result in two Filled messages for the same order. Counting every Filled message as another full trade would overstate the acquired quantity. Bybit private-order stream.
Use provider-defined identifiers and semantics for deduplication. A timestamp alone is not a universal unique execution identifier, and a custom local counter cannot replace the exchange's documented fields.
One fictional incident, two recovery records
Assume an application watches a market book and manages a spot order for 0.50 units. The last verified account observation shows a cumulative fill of 0.20 units. During a six-second observation gap, another 0.15 units fill. The final recovered cumulative quantity is 0.35, leaving 0.15 units on the original order.
These are hypothetical quantities, not a customer incident. Fees and prices are omitted because the example tests event interpretation.
| Lane | Before the gap | After reconnecting | Evidence still required |
|---|---|---|---|
| Market data | Book continuity verified through a recorded update boundary | Messages and heartbeat resume | Rebuilt or otherwise verified continuous book under the provider protocol |
| Private account | Order cumulative fill 0.20 of 0.50 | A status event reports cumulative fill 0.35 | Order identity, current state and any relevant execution records |
| Local accounting | 0.20 units already recorded | Same cumulative 0.35 event is observed twice | Count only the additional 0.15 once, using the applicable event semantics |
The increment is 0.35 - 0.20 = 0.15. The remaining quantity is 0.50 - 0.35 = 0.15. Adding the cumulative 0.35 twice would create a fictional 0.70 units and exceed the requested order size.
A real reconciliation must account for fees, cancellations, replacements and any other account activity. The table demonstrates one mistake without presenting subtraction of cumulative values as a universal accounting implementation.
What can resume, and what should wait?
The appropriate recovery boundary depends on what the workflow needs. A read-only display can show a clearly marked last observation while recovering. A strategy relying on continuous depth should not treat an unverified book as a fresh signal. An execution workflow needs a defensible account state before submitting actions that could duplicate or conflict with prior work.
This does not imply that every outage should trigger automatic cancellation. Some existing orders may be protective exits; removing them changes exposure. Nor does a socket disconnect guarantee an exchange-side cancel-on-disconnect feature is configured or available. Verify the exact product behavior rather than assuming a transport event changes orders.
If automation is paused, identify who manages the remaining exchange-held exposure. KLINEO's security guidance explains that removing a credential or stopping application activity does not automatically reverse fills or close positions.
Test the supported resume criteria in the appropriate environment. The testnet acceptance guide helps turn a vague reconnect test into observable checks: subscriptions restored, continuity recovered, original order found and no duplicate submission created.
Reconnection itself has a request budget
An outage can make many consumers reconnect at once. Authentication, subscriptions and REST snapshots can compete for provider capacity. If each failed reconnect immediately starts another full recovery, the recovery mechanism can sustain its own overload.
Use the documented connection and request limits, coordinate retries and respect provider retry instructions. A bounded delay and a clear degraded state are more useful than hiding an endless retry loop behind a spinner. Do not work around a ban by opening more sessions or changing keys.
The rate-limit recovery budget shows how ordinary low usage can leave too little capacity for a simultaneous recovery burst. Include snapshots and account reconciliation in that budget, rather than counting only steady-state stream messages.
Also reset the right state on subscription changes. A new instrument, account or environment should not inherit a previous subscription's supposedly verified sequence boundary. Shared transport can carry multiple topics, but each topic's state still has its own identity and continuity rules.
Keep the recovery record small and decisive
A useful incident note records the last verified boundary, the detected gap, the restored subscriptions, the state-recovery method and the final observation time. For affected orders, add their identifiers and final known cumulative fill and status. Keep secrets, authorization headers and full private payloads out of shared notes.
State what remains unresolved. “Public prices resumed at 14:03:15; private order recovery pending” is actionable. “Connection restored” can hide the more important half of the incident.
Review the record after client updates, new subscription types and provider protocol changes. A successful recovery for one market-data feed does not certify all private order streams. The intended result is a reader or operator who can explain why the data is trustworthy again, and who can identify exactly which account questions still need an answer.
Editorial method: Prepared with AI assistance on 20 October 2026 from current official market-stream and private-order documentation. The sequence gap, six-second outage and quantity table are original hypothetical constructions with independently checked arithmetic. No customer stream, production outage or live order was observed.