Appearance
Authentication
Tessium authenticates WebSocket connections with an API key.
Passing the key
| Method | Best for | Trade-off |
|---|---|---|
| Query string | Fast setup and local experiments | URLs can appear in proxy or connection logs |
| First message | Production services | Client must send auth before any other command |
Query string
Put the key in the query string when you open the socket:
wss://api.tessium.dev/stream?key=YOUR_API_KEYFirst message
To keep the key out of the URL, connect to wss://api.tessium.dev/stream and send this as the first message:
json
{ "op": "auth", "key": "tsk_live_..." }Create and rotate keys in the dashboard.
Recommended for production
Authenticate with the first message so reverse proxies and connection logs do not receive the key in the URL.
Keep keys server-side
Treat the key like a password. Do not embed paid keys in public frontends. The marketing demo may use a shared free key; production bots should keep theirs private.
Security checklist
- Store keys in environment variables or a secrets manager.
- Use separate keys for development and production.
- Never commit a key or print it in application logs.
- Rotate a key immediately if it may have been exposed.
- Revoke keys that are no longer used.
Authorization and limits
The key carries the plan of the account that owns it. Plan limits decide:
- which streams you may subscribe to
- how many concurrent subscriptions and connections you may hold
- which detail levels you may request
When a subscribe is denied, the server replies with an error frame that names the reason. Paid upgrades are settled in crypto from the pricing page or checkout in the dashboard.
Key states
A key can be active, suspended, or expired. Suspended and expired keys are rejected during authentication. A key revoked while connected produces key_revoked; stop using it and rotate the credential.