Private exchange WebSocket session expiry means account-event access can end even while the network connection remains alive. Track the venue's authentication and subscription lifecycle separately from heartbeats, renew or replace access using the documented mechanism, and verify the replacement subscription before relying on it. If observation was interrupted, reconcile affected account activity before treating the connection as ready for new decisions.
A quiet account stream creates an awkward question: did nothing happen, or did permission to observe it disappear? A price feed and a responding socket cannot answer that question. Private order and balance streams need their own evidence of authentication, subscription and renewal.
This guide explains that lifecycle using current official documentation and a hypothetical incident. Venue examples describe their specified protocols; they do not establish which private-stream methods KLINEO implements.
Keep four clocks in the connection record
The word “expiry” can refer to different objects. Before choosing a timer, identify what expires, who owns it and what acknowledgment establishes its current state.
| Clock | What it governs | Useful evidence | Mistake to avoid |
|---|---|---|---|
| Credential eligibility | Whether the underlying API credential remains usable for this account and permission scope | Current credential identity and a scoped authenticated check | Treating stream renewal as renewal of a revoked API key |
| Authentication request validity | Whether a particular signed login request arrives within its permitted time | Request deadline, response and clock-offset checks | Reusing yesterday's signed login after reconnecting |
| Private subscription or stream lease | Whether this session may continue receiving account events | Subscription identity, renewal acknowledgment or explicit expiry event | Assuming a pong extends every form of private access |
| Transport lifetime and idle policy | Whether the socket remains open | Connection creation time, heartbeat results and close reason | Calling an open socket an authenticated account connection |
These clocks may interact, but one successful check does not reset all of them. A renewed stream lease can still sit on a connection approaching its maximum lifetime. A fresh socket can still lack a successful private subscription.
Keep the account, environment and product beside every record. A renewal result from another subaccount or test environment cannot validate the session managing live exposure. The broader connection-health worksheet gives these observations a scope and timestamp.
Read the exact protocol before copying a renewal recipe
Binance's documented COIN-M user data stream uses a listenKey valid for 60 minutes. Its specified PUT operation extends that validity by 60 minutes. The same documentation sets a separate 24-hour maximum connection lifetime. Crucially, its listenKeyExpired event is independent of a WebSocket disconnection: account events stop until a new valid key is used. Those are three distinct lifecycle rules for this particular protocol. See Binance COIN-M user-data-stream lifecycle and expiry.
Bybit V5 describes private authentication with an expires timestamp later than the current time, plus an authentication success response. It separately recommends a ping every 20 seconds and documents an idle policy controlled by max_active_time. The authentication request's expires field is not evidence that the authenticated socket must be renewed at that same interval. Keep the request deadline and idle policy separate when reading Bybit V5 connection and authentication documentation.
Even one provider can expose several mechanisms. Binance Spot documents WebSocket API user-data subscriptions and subscription-status methods, including different authenticated and signed subscription routes. A derivatives listen-key recipe is therefore insufficient evidence for a Spot implementation. Consult the Binance Spot user-data-subscription reference for that scope.
Choosing a credential mechanism also requires separate verification. The guide to HMAC, RSA and Ed25519 exchange keys explains the material and signing differences. A key type supported somewhere in an API does not establish support for every login or subscription method.
A hypothetical renewal that never ran
Consider a deliberately simplified protocol with a 60-minute private-stream lease. Assume the lease begins exactly at 12:00, the client plans renewal at 12:40, and no extension occurs. These times illustrate scheduling risk; 40 minutes is an invented client policy, not an exchange recommendation.
The nominal expiry is 12:00 + 60 minutes = 13:00. The planned renewal leaves 60 - 40 = 20 minutes of headroom. At 12:35, however, the renewal worker is suspended while a separate socket process stays connected. Its scheduled task never runs.
| Time | Observed event | What the operator can conclude |
|---|---|---|
| 12:00 | Stream lease established | The documented lease clock starts under the example's assumptions |
| 12:35 | Renewal worker stops progressing | A future scheduled job is no longer evidence of renewal |
| 12:40 | Planned renewal time passes without a request | No acknowledged extension exists |
| 13:00 | Private lease expires; transport remains open in this fixture | Heartbeats cannot certify private event access |
| 13:02 | Monitoring detects the missing renewal acknowledgment | Mark private observation unavailable and identify affected activity |
| 13:03 | Replacement access and subscription are acknowledged | New private observation is established; the earlier gap remains |
| 13:06 | Account queries and event comparison finish | Resume only if the defined account-recovery checks pass |
In this fixture, the authorization gap lasts three minutes, from 13:00 to 13:03. The conservative operational recovery lasts six minutes, until 13:06. Neither interval proves that any order did or did not fill. This distinction prevents a replacement-session acknowledgment from erasing the account questions created by the gap.
An actual API may report a server expiry time, use a different renewal operation, or invalidate access earlier. Use that protocol's evidence rather than treating this local arithmetic as a server guarantee.
Renew from acknowledged state
Record the last confirmed renewal, the next planned attempt, the applicable deadline and the responsible worker's progress. A scheduled job is an intention. A transmitted request is an attempt. A successful provider acknowledgment is evidence of acceptance. Keep those states distinct in logs and alerts.
If a renewal times out, do not advance the confirmed lease deadline merely because the request left the machine. The provider might have processed it, but the client has not established that result. Follow the documented query, repeat-renewal or replacement behavior, with bounded retries and the provider's request limits. Avoid inventing an idempotency guarantee for a lifecycle operation.
Use elapsed-time scheduling that handles process pauses, while preserving server timestamps for protocol checks and audit records. After a restart, recompute the state from stored acknowledgments and the current protocol instead of restoring an old “connected” flag. A machine that slept through renewal needs a recovery decision, not a timer reset.
Keep raw keys, signatures, authentication payloads and private stream tokens out of shared incident notes. Store only the non-secret identifiers needed to match the session and account. Replacing a temporary stream token is also different from rotating the underlying exchange API key.
Set a clear boundary for resuming
A useful state progression is: transport connected, authentication accepted, private subscription accepted, account state verified. Each step needs its own evidence. Where a protocol combines steps, retain the provider's actual response semantics rather than inventing extra acknowledgments.
When replacement overlaps an older session, expect that the same account activity may be observed through both. Apply the venue's execution identities and event semantics so a handoff cannot count one fill twice. When there is a gap, use complete paginated exchange history where required; the first returned page does not establish complete coverage.
The existing WebSocket recovery guide handles market continuity and account reconciliation in detail. Here the narrow resume condition is that private authorization is established for the intended account and any activity hidden during renewal failure is resolved to the required standard. Do not interpret a lost subscription as an instruction to cancel protective orders or as proof that exchange-held orders stopped working.
Test delayed renewal, rejected credentials, a lost acknowledgment, a process restart, overlapping sessions and a quiet account with no natural events. Record the observable result for each. A quiet stream is a valuable test precisely because absence of account messages cannot distinguish inactivity from lost authorization.
Editorial method: Prepared with AI assistance on 23 October 2026 from official Binance and Bybit documentation. The four-clock worksheet and timed incident are original teaching constructions. No live connection, customer incident or product renewal implementation was observed.