Protocols and formats

WebSocket

Text or binary frames. A common format is JSON: { "tenant": "...", "channel": "...", "payload": "..." }. Subscribe and control messages use the same transport. Exact message types and frame layout depend on your deployment; ask your operator or see the API docs.

WebTransport

Browser-oriented transport over QUIC / HTTP/3 on a single connection. Compared with one bidirectional WebSocket, this is often much better when you need many logical streams: you can open multiple independent send/receive streams without head-of-line blocking between them, so one slow or large stream does not stall the rest.

Where the deployment exposes it, unreliable datagrams are a strong fit for game-style traffic—position updates, aiming, short control signals—cases where latest state matters more than delivering every prior packet. Reliable streams on the same session can still carry chat, inventory, or anything that must arrive in order.

The logical tenant/channel/message model matches WebSocket where both are offered. Framing, which features (streams vs datagrams, sizes, backpressure) are enabled, and URLs still depend on deployment—confirm with your operator.

REST

JSON request and response bodies. All token endpoints are under /v1/. See REST API and the server’s OpenAPI (Swagger) docs at /swagger-ui for the full schema.

Tokens

Access tokens are strings like AT_<token_id>_<secret>. They are created via the REST API (POST /v1/get-token) and passed when opening WebSocket (Authorization header or Sec-WebSocket-Protocol subprotocol) or WebTransport (per deployment docs—often bearer-style headers at session setup). See Tokens.

Errors

For typical authentication/permission failures and common disconnect reasons, see Error codes.