Start recording room audio
Start one persistent mixed Recording of the room.
The Recording remains active while the room is empty and across service recovery.
A 202 response confirms that the start request was accepted. It does not
mean the Recording is available yet. The response also includes the current
Recording details:
- The
recording_uuid. - A signed, time-bounded public
media_url, without internal paths.
Availability is reported separately:
- If the Recording becomes available, the platform emits
recording.became_available. - If the Recording does not become available, it remains active and the
platform does not emit
recording.failed.
When you later stop the Recording, the platform emits recording.ended.
See Recording lifecycle events for complete payload schemas and examples.
Authentication
Send Authorization: Bearer <app_uuid>:<api_key> using an active API key. See Authentication for details.
Path parameters
Case-sensitive room identifier.
Headers
Optional key for safely retrying mutating requests. An explicitly empty header is treated like omission and does not enable replay protection. See Idempotency for details.
optional client-supplied lowercase RFC-4122 v4 UUID returned as operation_uuid; platform generates one when omitted; correlation metadata distinct from Idempotency-Key.
Response headers
Server-owned W3C Trace Context for correlating this response with support and observability data. It is present on successful and error responses. A valid incoming traceparent is linked to, but never becomes, the server-owned trace identifier.
Response
Stable Recording identifier starting with rec_.
Exact expiry instant of media_url, derived from the URL’s signed expiration.
Starts at byte zero and follows the growing Recording until EOF. After finalization, the same URL serves a finite, range-capable WAV. Validity defaults to 24 hours.
Owning Room; mutually exclusive with session_uuid.
Owning Session; mutually exclusive with room_id.