WebSocket Errors

The feed surfaces problems in three places, depending on when they occur:

1. At the handshake: authentication failures, reported as an HTTP status before the connection opens.
2. In a reply: a subscribe / unsubscribe that can't be honoured, reported with status: "error" while the connection stays open.
3. In-stream: a generic error message for malformed input or server-side problems.

Handshake failures

The token is validated during the WebSocket upgrade. A missing, malformed, or revoked key is rejected with HTTP 401 and no WebSocket connection is opened. Most clients surface this as a connection error at connect() time, not as a close frame. Handle it where you handle connection failures, and do not retry with the same bad key. See Authentication.

Subscribe / unsubscribe errors

A subscribe or unsubscribe that can't be honoured is rejected with status: "error" and a reason. The connection stays open. Fix the request and resend.

{ "type": "subscribe", "status": "error", "reason": "unknown channel: bet" }

reason	Meaning	Client action
unknown channel: <name>	The channel is not a recognised, subscribable channel. Only event and market are available to a partner key; any other value — including internal channels — is reported this way. The reply carries no channel field and does not distinguish an internal channel from an unrecognised name.	Subscribe only to event or market.

See Subscriptions for the full subscribe model.

In-stream errors

For malformed input or server-side issues, the server sends a generic error message. The connection generally stays open.

{ "type": "error", "message": "Unknown message type: subcribe" }

Field	Type	Description
type	string	Always "error"
message	string	Human-readable explanation, intended for logging and debugging. Not a stable code, so do not branch on its text.

Common causes:

• The message was not a JSON object with a type field.
• The JSON could not be parsed.
• The type was not a recognised message type.
• The connection was not authenticated.

These are almost always client bugs. Log the message and fix the offending request.

Close codes

When the server closes a connection it uses a standard WebSocket close code per RFC 6455 §7.4. Treat a close as a signal to reconnect with backoff and re-subscribe (see Reconnecting); the close code tells you how cautious to be.

Code	Meaning	Client action
1000	Normal closure (e.g. graceful server shutdown)	Reconnect with backoff.
1001	Server going away (e.g. deployment)	Reconnect with backoff.
1006	Abnormal closure: connection dropped without a close frame (network blip)	Reconnect with backoff.

A handshake authentication failure is reported as HTTP 401, not a close code, because it happens before the connection is established.