After creating a session, open a WebSocket to send and receive events in real time.Documentation Index
Fetch the complete documentation index at: https://docs.poly.ai/llms.txt
Use this file to discover all available pages before exploring further.
Connecting
wss://<base-url>/ws
Query parameters
| Parameter | Required | Description |
|---|---|---|
session_id | Yes | The session ID from the Create Session response |
access_token | Yes | Your access token |
cursor | No | Resume from a specific point in the conversation. Format: seq:<n> where <n> is a sequence number. Default: seq:0 (full history). |
The access token is passed as a query parameter (not a header) because WebSocket connections do not support custom headers during the handshake. All connections use TLS encryption.
Connection limits
| Constraint | Value |
|---|---|
| Idle timeout (no messages) | 10 minutes |
| Maximum message size | 128 KB |
| Concurrent connections per session | 10 |
What happens on connect
When the WebSocket opens, the server immediately sends the session history as one or moreEVENT_TYPE_EVENT_BATCH events. This lets your client reconstruct the conversation state — especially useful when reconnecting after a network drop.
The first batch always contains at least the EVENT_TYPE_SESSION_START event, which tells your client about the session’s capabilities (e.g. whether streaming is enabled).
After processing the history:
- New session (no
EVENT_TYPE_POLY_AGENT_JOINEDin the replayed events): sendEVENT_TYPE_REQUEST_POLY_AGENT_JOINto start the conversation. - Reconnect: the agent has already joined — skip the join request.
Keeping the connection alive
SendEVENT_TYPE_HEARTBEAT events at regular intervals to prevent the connection from timing out. The server echoes each heartbeat back.
If the server receives no messages (including heartbeats) for the idle timeout period (10 minutes), the connection is closed and the session will eventually end.
Reconnecting
If the connection drops, reconnect using the samesession_id and access_token. Pass the cursor parameter to avoid replaying events you’ve already received:
lastSequence to the highest sequence number your client has seen. The server replays only events after that point.
Recommended reconnect strategy
- Implement exponential backoff: start at 1 second, cap at 30 seconds
- Use
capabilities.max_reconnect_attemptsfromSESSION_STARTas a hint for how many times to retry - After exhausting retries, surface an error and let the user start a new session

