Session
A Session is the addressable unit of a voice interaction: one phone call or
standalone WebSocket audio endpoint that your application can inspect and
control. SIP and WebRTC participants are planned for a future release. A
Room connects multiple Sessions into a shared conversation,
while playback, DTMF collection, recording, and WebSocket audio operate on an
individual Session.
How Sessions are created
Sessions enter your application in several ways:
The lifecycle field depends on the endpoint: each item returned by
GET /sessions uses state, while
GET /sessions/{session_uuid}
uses status. Both use the same values: new, connecting, ringing,
early_media, answered, or ended. Treat either as a point-in-time
snapshot for inspection and reconciliation. Webhooks are the asynchronous
event stream for reacting to lifecycle changes as they happen. Every Session
finishes with exactly one terminal
call.ended webhook, whether it was
answered, rejected, timed out, disconnected, or explicitly deleted.
What you can do with a Session
Use the session_uuid to:
- inspect one Session or list the Sessions owned by your application;
- answer an incoming call or request termination;
- play audio and collect DTMF digits;
- start and control a Session recording;
- attach a bidirectional WebSocket audio relay; and
- add the Session to a Room, then control its membership there.
Most control commands are asynchronous. An accepted command returns
202 Accepted with an operation_uuid; the command’s reference identifies the
webhook that confirms completion or reports the resulting lifecycle change.
Methods
- Originate an outbound call
- Create a standalone WebSocket session
- List sessions
- Get session details
- Answer an incoming session
- Delete a session
Session lifecycle, Playback, DTMF, and WebSocket commands operate on a session by
placing its session_uuid in the {uuid} path parameter. Recording commands
create and control a Recording owned by that Session.