The core challenge of integrating Binance private data streams is not "getting connected." It is "how to keep your local state consistent with the exchange after you connect." Spot, USD-M futures, COIN-M futures, and options each have their own listenKey mechanism. The validity periods, WebSocket addresses, and event fields are not exactly the same. Reconnecting after a disconnect is not complicated by itself. The difficult part is how to fill in the orders and balance changes you missed while disconnected. The advice from the official Binance developer community is direct: after the stream disconnects, use REST API queries to check and fill in the gaps. There is no smarter shortcut.
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!
First, know which market your private stream belongs to
Binance private data streams are not one unified system. Whether you connect to spot, USD-M futures, COIN-M futures, or options, the listenKey creation endpoint, validity period, and pushed events are different.
Spot private streams can be subscribed through the WebSocket API, or through the traditional listenKey method. After creation, a spot listenKey is valid for 60 minutes. You can extend it by 60 minutes with PUT. The connection itself will be disconnected after a maximum of 24 hours. The pushed events include executionReport for order updates and outboundAccountPosition for balance changes.
USD-M futures listenKey is also valid for 60 minutes, extended with PUT, with a 24-hour connection limit. The WebSocket address is wss://fstream.binance.com/private, and the subscription format is /ws/. It pushes ORDER_TRADE_UPDATE and ACCOUNT_UPDATE.
COIN-M futures works similarly, but the event fields and push logic have small differences. ACCOUNT_UPDATE pushes position information for all symbols instead of only the changed part.
Options uses a different private stream address, with the same 24-hour connection limit. ACCOUNT_UPDATE is pushed periodically every 10 seconds if you have positions. This periodic push has an extra use during reconciliation after disconnects, which I will explain later.
There is a relatively new change: Binance has introduced the listenToken solution as the recommended replacement for listenKey. You get a token through POST /sapi/v1/userListenToken. The default and maximum validity period is 24 hours, much longer than the 60 minutes of listenKey. Subscribe through the WebSocket API method userDataStream.subscribe.listenToken. If you do not renew it before expiry, the stream pushes an eventStreamTerminated event and then stops pushing any data until you create a new token and resubscribe. If you are building a new project, prioritize listenToken. It needs less frequent renewal and removes one scheduled task.
Order and balance push logic determines how you reconcile
Spot order updates use executionReport, and balance changes use outboundAccountPosition. There is an old problem discussed many times in the Binance developer community: these two events have no direct correlation field. You receive an executionReport showing that an order was filled, and the following outboundAccountPosition will reflect the balance change. But you cannot confirm from the event itself that "this balance change was caused by that order."
Binance does not provide an order ID mapping between executionReport and outboundAccountPosition. The common community approach is to optimistically update the local balance based on the fill data in executionReport, then overwrite it when outboundAccountPosition arrives. This assumes that executionReport always arrives before the corresponding outboundAccountPosition. Under normal load this assumption usually holds, but Binance does not promise strict ordering, so the overwrite logic is necessary.
For futures, ORDER_TRADE_UPDATE and ACCOUNT_UPDATE are separate. Futures ACCOUNT_UPDATE has an important feature: unfilled or canceled orders do not trigger this event, because positions and balances do not actually change. In other words, if you place a limit order that is not filled, you will only receive ORDER_TRADE_UPDATE, not ACCOUNT_UPDATE. If you rely only on ACCOUNT_UPDATE to track order status, you will miss open orders and cancellations.
Regarding event ordering, the official documentation clearly states that for the same event type on the same connection, T (match engine trade time) and E (event generation time) are strictly ordered. It is recommended to use the E field for ordering across event types, especially when comparing ORDER_TRADE_UPDATE with market data streams.
Reconciliation after reconnection has no shortcut
Reconnection itself is simple: after the WebSocket disconnects, check whether the listenKey is still valid. Futures listenKey expires in 60 minutes, so if the downtime is short you can reconnect with the old key. If you receive a -1125 listenKey does not exist error or a listenKeyExpired event, create a new one with POST. When a spot listenKey expires, it pushes a listenKeyExpired event and then stops pushing any data.
The key is what happens after reconnection. Trades and balance changes that happened during the disconnect will not be replayed over WebSocket. The Binance developer community advice is: after the stream disconnects, actively use REST API queries to check and fill in the gaps. Specifically, check the following:
Orders: use GET /api/v3/openOrders for spot, or the corresponding futures endpoint, to check current open orders. Use GET /api/v3/allOrders or GET /fapi/v1/allOrders to check order history. Compare against your locally recorded order states. Focus on orders whose status changed from NEW or PARTIALLY_FILLED to FILLED or CANCELED within the disconnect time window.
Balances: use spot GET /api/v3/account or futures GET /fapi/v2/account to pull the full balance and overwrite your locally cached balance. Do not try to "fill in" using incremental events. Direct full overwrite is the most reliable.
Options has a slightly better condition: ACCOUNT_UPDATE is pushed periodically every 10 seconds when you have positions. This means even if you miss one or two change events, you will receive a full or semi-full account state push within at most 10 seconds. The reconciliation window is shorter than for spot and futures. But fills can still happen within that 10-second window, so REST reconciliation is still needed.
An easy-to-miss pitfall: futures testnet ACCOUNT_UPDATE may not be pushed
A June 2026 post on the Binance developer community reported a problem where testnet futures account ACCOUNT_UPDATE events were not pushed at all. Orders were filled, ORDER_TRADE_UPDATE was received normally, and the userTrades and income endpoints could query fees and realized PnL. But ACCOUNT_UPDATE never triggered, and REST positionRisk and account.totalWalletBalance also stayed at old values.
The premise of this problem is a specific testnet account. Whether the mainnet can have a similar situation cannot be confirmed from that post. But it points to a reconciliation strategy: do not assume ACCOUNT_UPDATE will always arrive. If your strategy depends on ACCOUNT_UPDATE to update positions and balances, when you have not received this event for a long time, you should actively use REST to pull the account state once for verification instead of waiting indefinitely. The account in the post later passed the knowledge quiz and reset the wallet, but the aggregator did not remount the event stream, so the state stayed frozen. If you see a similar situation on mainnet, contact Binance support instead of repeatedly reconnecting on your own.
Practical integration advice
If you are building a new project, use listenToken instead of listenKey. The 24-hour validity reduces the complexity of renewal logic, and the eventStreamTerminated event makes expiry handling clearer. If you are maintaining an existing system, listenKey still works, but make sure the 60-minute renewal scheduled task is correct. When PUT fails with -1125, immediately create a new one with POST. Do not retry PUT.
Do reconciliation in this order: after successful reconnection, first pull full balances and open orders via REST and overwrite local state; then query order history within the disconnect time window and correct local order states; then resume WebSocket incremental processing. Do not try to use events to fill the gap during the disconnect. It cannot be done.
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!
References
- Binance Developers·Listen Token User Data Stream, no update date shown; checked on 2026-10-21.
- Binance Developers·Account Information Stream (USD-M Futures), no update date shown; checked on 2026-10-21.
- Binance Developers·User Data Streams (COIN-M Futures), no update date shown; checked on 2026-10-21.
- Binance Developers·User Data Streams (Options), no update date shown; checked on 2026-10-21.
- Binance Developers·Trade Data Stream (Spot, deprecated), no update date shown; checked on 2026-10-21.
- Binance Developer Community·WebSocket account push disconnect and reconnect, no update date shown; checked on 2026-10-21.
- Binance Developer Community·User Data stream events consistency, no update date shown; checked on 2026-10-21.
- Binance Developer Community·Testnet Futures account: ACCOUNT_UPDATE events not emitted, no update date shown; checked on 2026-10-21.
