Skip to main content

Reconnecting

Disconnects are normal: network blips, client restarts, deployments. This page explains exactly what the feed does and does not do on reconnect, so you can keep your local state correct.

What the feed does not do​

The feed has no replay and no resume. Specifically:

  • There is no message buffer or cursor. The server does not retain messages for you while you are disconnected, and there is no "resume from where I left off" mechanism.
  • There are no per-message sequence numbers. You cannot detect a gap by comparing message IDs.
  • Subscriptions are dropped on disconnect. When the connection closes, the server forgets what you were subscribed to.

The practical consequence: any messages sent while you were disconnected are gone. After a reconnect your local state may be stale, and the feed will not tell you which entities changed in the gap.

How to reconnect correctly​

  1. Reconnect to /ws with your token (see Authentication), with a backoff between attempts.
  2. Re-subscribe to every channel and filter you need. Send the full filter set; subscriptions do not carry over (see Subscriptions).
  3. Re-establish a baseline from REST for anything where staleness matters. Because no messages are replayed, fetch the current state of your subscribed events/markets via the REST API, then apply live WebSocket updates on top of it.

If you maintain your subscription list on the client, step 2 is just resending it. The subscriptions message lets you confirm what the server now has after you re-subscribe:

{ "type": "subscriptions" }

Note that subscriptions reports current subscription state only. It does not replay any data.

For state that must be accurate (e.g. current price per selection), treat REST as the source of truth for the baseline and the WebSocket feed as the source of changes:

  • On first connect, and on every reconnect, load the baseline from REST.
  • Apply WebSocket updates as they arrive.
  • On any disconnect, discard nothing prematurely, but re-baseline from REST on reconnect before trusting your local state again.

For low-frequency, non-critical data you may simply re-subscribe and let the next update refresh your view.

The event_sync hint​

On the event channel the server may send an event_sync message ({ "type": "event_sync", "message": "event_change" }). It carries no data. It means event-level data has changed: reload your event list from GET /events and reconcile it with what you hold, without waiting for a disconnect. It arrives even if your event subscription is filtered by event_ids. See Message Format.