Skip to main content
Authenticating your WebSocket connection tells the server which account the connection belongs to. While some private channels currently accept an account address directly in the subscription parameters, sending an Auth message first is the recommended pattern — it ensures your connection is ready for all private streams and is required for any future access-controlled features.

​
Sending the Auth message

After opening the WebSocket connection, send the following JSON frame:
​
string
required
Must be the fixed string "Auth". This identifies the message type to the server.
​
number
required
Your numeric account ID. This is the value returned by the registerAccount action — not your wallet address.

​
Server response

The server replies with an AuthResult frame on the same connection:
​
boolean
true if the authentication was accepted. false if the accountId was not found or was invalid.
​
number
Echoes back the accountId from your request so you can correlate the response in async handlers.

​
Error response

If authentication fails, the server returns a success: false result:
Check that the accountId was registered on-chain via registerAccount before retrying.

​
After authenticating

Once you receive "success": true, you can subscribe to any channel — including orderUpdates, openOrders, and userFills — and the server will associate those streams with your account context.
Private channels (orderUpdates, openOrders, userFills) currently accept the account address directly in the subscription user field without requiring prior Auth. However, authenticating first is strongly recommended for forward compatibility — the access model may tighten in future releases.
Re-send your Auth message immediately after every reconnect, before re-subscribing to any channels. This keeps your connection authenticated without any gap in coverage.