Connection
How the WebSocket connection behaves under load and over time. Heartbeat, reconnection, and close codes.
The CoreX WebSocket connection is what carries every event to your backend. This section is the reference for how it behaves over time and what to do when things change.
Topics
| Page | What it covers |
|---|---|
| Heartbeat | How to keep an idle connection open. Protocol pings and the text fallback |
| Reconnection | Backoff strategy, token re-mint, and what arrives first after a successful reopen |
| Close codes | What each close code means and how your client should react |
The basics
If you’ve already followed Quickstart, you’ve seen the lifecycle: mint a short-lived token, open a WebSocket, receive a resumed event, then events stream as they happen. The first message after every successful handshake is always resumed, and it confirms your maxSubs cap.
If your connection drops, the workflow is the same: mint a new token and open a new WebSocket. There is no resume-from-sequence; reconnecting brings you back live without replaying events you may have missed during the gap. See Reconnection for the recommended client logic.