Skip to main content
A WebSocket integration needs a published endpoint and message protocol. The current public resource API does not establish a general Threetone WebSocket conversation endpoint, event stream, or supported client package.
Do not derive a socket URL by replacing https with wss on an API route. A signed-URL or token operation in the reference does not establish a WebSocket protocol, and conversation execution remains gated by current availability.

​
Specify the integration before connecting

Keep workspace credentials in your server’s secret storage. Give the application only the access permitted by the released session contract. Avoid putting long-lived credentials in URLs, which can be retained in logs.

​
Plan failure handling

1

Use an explicit connection state

Distinguish connecting, open, closing, and closed. Send only when the connection is ready, and stop accepting new work after the owning session ends.
2

Bound outgoing work

Set a queue limit and an application response to overload. The standard WebSocket API has no automatic backpressure; a growing buffer needs deliberate handling.
3

Treat reconnect as a protocol decision

Retry transient failures with a bounded delay only when the released protocol permits it. Do not replay tool actions, user messages, or audio unless the protocol defines safe replay or deduplication.
Before release, test malformed messages, expired access, duplicate events, slow consumers, abrupt disconnects, and cleanup. Record identifiers and error codes without logging access tokens or full customer payloads. Use server deployment for supported resource requests and client events for the separate event-contract boundaries.

​
Frequently asked questions

No. It returns a workspace count. It is not a transcript subscription or socket endpoint.
No. Saved event preferences require a released producer, transport, and authorization contract before a client can subscribe.