> For complete lifecycle-event payload schemas and examples, use the canonical overview: Session /api/sessions; Room lifecycle, members, and room playback /api/rooms; Session playback /api/playback; Recording /api/recording; DTMF /api/keypad-input; Messages /api/messages; WebSocket Session /api/web-socket. Use /api/event-delivery for transport behavior. Endpoint pages name relevant events, but these overviews are the canonical references.

# Room Playback overview

> Room Playback API overview; complete room-playback event schemas and examples are in the Room overview.

Room Playback plays URL-based audio into a room for every member to hear. Start with [Play audio in room](/api/room-playback/play), then [seek](/api/room-playback/seek), [pause or resume](/api/room-playback/pause), [set volume](/api/room-playback/volume), or [stop](/api/room-playback/stop).

## When to use

Use Room Playback when everyone in a Room should hear the same audio, such as
an announcement or prerecorded message.

To play finite files, include `type: "files"` and a non-empty `urls` array. The
`type` field is required.

These commands return `202 Accepted` when accepted for processing. Every command accepts an optional `Operation-Id` request header containing a lowercase UUID v4; the response returns the selected value as `operation_uuid`, generating one when the header is omitted. Use `Idempotency-Key` separately for safe retries.

Every playback that starts produces exactly one terminal event: [`room.playback.ended`](/api/rooms#roomplaybackended) or [`room.playback.failed`](/api/rooms#roomplaybackfailed). The terminal event's `operation_uuid` correlates it with the original play request. When playback is stopped through the API, the stop request's own `202 Accepted` response carries its separate effective `operation_uuid`.

Room Playback controls the shared mix. Use [session playback](/api/playback) for audio aimed at one session.