Playback events
Playback events track audio playback on active calls, including start, completion, and error states. Each playback command also emits a dedicated domain lifecycle event correlated via operation_uuid.
The correlation field on every webhook here is operation_uuid. Lifecycle
events normally echo the 202 Accepted response for the command that owns that
playback. A terminal event caused by a later playback/stop retains the original
start or silence operation UUID.
playback.started
Fired when the call leg begins playing the requested audio or silence stream. Receipt of playback.started means playback is active on the leg. For a multi-file URL playlist, it does not guarantee that every later item has already been fetched or decoded.
Payload schema
Measuring playback start latency
The timestamp field lets you estimate how long it took between requesting playback and audio reaching the caller. Parse the RFC 3339 string to a millisecond epoch value, then subtract the wall-clock milliseconds at which you sent the POST /playback/play request:
Record the time you issued the playback/play request, parse timestamp when the playback.started webhook arrives, and subtract.
Cross-clock caveat — treat the result as approximate. The event timestamp and your POST-request time come from different clocks and can differ slightly. Use the computed latency for trend monitoring and relative comparisons, not as an exact, sub-millisecond measurement. A small negative value (e.g. the webhook timestamp appearing slightly before your send time) is possible under clock skew and should be treated as ~0.
playback.stopped
Fired when playback completes normally or is stopped via the playback/stop command. The offset_ms field indicates where finite file playback ended. Each accepted playback that starts emits exactly one playback.stopped event on completion or interruption. An accepted playback that cannot start emits playback.failed. A live stream or silence normally runs until it is replaced, stopped, or the session ends. A finite source rejected by the request-time probe emits no playback lifecycle event.
Payload schema
playback.failed
Fired when an accepted playback command cannot be completed. Before a finite type: files request is accepted, the gateway probes each URL with HEAD or a ranged GET; if a source cannot be prepared, the HTTP request fails synchronously and no playback webhook is emitted. After acceptance, playback.failed covers playback that still cannot start within the allotted window. Stream and silence playback can also fail with a timeout, and playback/restart fails when no playback is active. play_and_get_digits does not emit this event. Inspect the reason field to determine why the command failed.
Payload schema
command.playback.pause.accepted
Fired when an active playback pause command is accepted and dispatched. This event confirms command dispatch only.
Payload schema
command.playback.resume.accepted
Fired when a playback resume command is accepted and dispatched. This event confirms command dispatch only.
Payload schema
command.playback.seek.accepted
Fired when a playback seek command is accepted and dispatched. The offset_ms
field carries the requested position. This event confirms command dispatch only.
Payload schema
command.playback.restart.accepted
Fired when a playback restart command is accepted and dispatched. This event confirms command dispatch only.
Payload schema
Triggered by
These events are produced by the following commands:
playback.started— playback/play (Asynchronous).playback.stopped— playback/play (completion or interruption) and playback/stop.playback.failed— playback/play and playback/restart.command.playback.pause.accepted— playback/pause (Immediate).command.playback.resume.accepted— playback/resume (Immediate).command.playback.seek.accepted— playback/seek (Immediate).command.playback.restart.accepted— playback/restart (Immediate).