Connection flow

Connection flow is split into two stages: resolve an endpoint through the balancer, then open and use the WebSocket session.

End-to-end flow

Resolve a WebSocket endpoint by calling the load balancer.

Open WebSocket connection to the returned endpoint.

Store Resume-Id from handshake response headers for possible session recovery.

Send Initialize as the first API packet.

Authorize if needed with license or credentials.

Use packets and events on the same session until disconnect.

Minimal client sequence

1. GET /v1/websocket/server
2. connect to returned wss://... endpoint
3. read Resume-Id response header
4. send Initialize
5. send authorization packet if needed
6. continue with normal API usage

Handshake rules

Connect directly to the endpoint returned by the balancer.
After successful connect, store the latest Resume-Id response header.
There is no separate balancer-issued authorization token in the current flow.

Initialization rules

Initialize must be the first API packet sent after connect.
Until Initialize succeeds, other client packets are not allowed.
If initialization is not completed in time, server closes the session with close code 4202.

Reconnect rules

Use the balancer again when:

starting a completely new session;
previous endpoint is unknown;
session resumption is not being attempted;
previous session can no longer be resumed.

Do not use the balancer again when:

you are resuming an interrupted session and still have both the previous endpoint and Resume-Id.

In resume flow, reconnect to the same endpoint first and send the stored Resume-Id in the handshake. Full resume behavior is documented on Session resumption.

Practical notes

Keep balancer resolution and WebSocket transport as separate client stages.
Persist Resume-Id only for the current logical session.
Expose location from balancer response if you want region diagnostics in UI or logs.
For packet formats, see Client packets.