One key for REST and the stream
The stream authenticates with the same signed API key you use for the REST API — an Ed25519 keypair whose public half is registered to your actor. There is no separate stream credential. You sign the handshake with your private key exactly the way you sign a REST request; the private key never leaves your side.Signing the handshake
Because a browser cannot set custom headers on a WebSocket upgrade, the signed credentials ride the query string:
The canonical string is the REST canonical with the method literal
WS, the
sorted query excluding keyId/timestamp/signature, and the empty-body
hash:
WS method means a handshake signature can never be
replayed against a REST request on the same path, and vice versa.
Signing it is a few lines with the standard library — the same Ed25519 signature
you produce for REST, over this canonical string:
Handshake responses
The outcome of authentication is an HTTP status on the upgrade request, before any frame is sent:
Once the upgrade succeeds the server immediately sends a
welcome frame. From there, see
Subscriptions & markets to start streaming.