Sessions
A session attaches a configuration to a single live call and runs it in realtime. While the call is connected, the session taps the audio and runs the configured operators — turn by turn as the conversation unfolds, and once over the full transcript when the call ends.
Starting a session
You create a session with the call to analyse and the configuration to apply:
call_id— the live call to analyse. It must already be known to the platform.configuration_id— theuuidof the configuration to apply. It must be one of your account's active configurations.customer_metadata— an optional opaque object stored with the session and echoed back, verbatim, on every webhook the session fires. Use it to carry your own correlation keys.transcript_events— when true, transcript turns are emitted on the session's event stream alongside operator results.
The response returns a session_id; use it on every other session endpoint.
You don't have to start sessions yourself: assign a configuration to a trunk and the platform starts a session automatically for every call over it. Creating a session explicitly is the per-call alternative, for when you choose the configuration dynamically or attach per-call metadata.
Lifecycle
A session runs for the life of the call and ends automatically when the call ends — you don't tear it down yourself. As it ends, any conversation_end operators run over the full transcript. Within one session a configuration can blend both cadences: turn operators give you live signals during the call, while conversation_end operators produce the post-call analysis.
A session moves through a status over its life — established while running, then ending, ended, failed, or timed_out.
Retrieving results
A live session exposes its results two ways:
- Stream — call
GET /sessions/{session_id}/stream-tokenfor a short-lived token, then connect toGET /sessions/{session_id}/eventsto receive operator results over Server-Sent Events as they are produced. See Session events for the event types and payload shapes. - Snapshot — call
GET /sessions/{session_id}/operator-resultsfor the latest result per operator without holding a stream open.
Results can also be pushed to your systems as webhooks when they meet a condition, without retrieving them yourself.
Changing or ending a session early
PATCH /sessions/{session_id} swaps the configuration in force from that point in the conversation onward, or toggles transcript streaming for the rest of the session — so you can adapt the analysis mid-call. DELETE /sessions/{session_id} ends a session before the call ends, when you want to stop analysing early; in the normal case the session ends on its own when the call does.
A session is live and ephemeral. What persists after the call is the conversation — the durable record you query afterwards.