RTC HTTP API: continuous recording, archives, playback, and download

Use the public contract matching the deployment version. roomId identifies a meeting; recordingId identifies one recording run, and a room can have several runs. The current host or a business API with rtc.manage controls capture. Historical viewing uses separate rtc.recordings.view/play/download grants or a short-lived archive ticket issued by an authorized backend. An in-meeting RTC token cannot replace an archive ticket.

During the meeting: allow, start, query, stop

Legacy recording/start, recording/stop, and recording/targets operate per publication and do not replace whole-meeting recording. During the meeting, original audio and video are copied in their existing encoding as independent tracks. Member/screen playback copies and a full-meeting MP4 are built afterward. Muted or disconnected periods keep real gaps rather than replaying frozen media.

Backend: issue a room-bound archive ticket

POST /api/v2/rtc/rooms/{roomId}/recordings/access
Authorization: Bearer <backend platform session or API token>
Content-Type: application/json

{"actions":["view","play","download"],"lifetimeSeconds":120}

actions accepts only view/play/download. Default is view+play; requesting play or download also includes view. Lifetime defaults to 120 seconds and is clamped to 30–600. Response includes token, roomId, effective actions, expiresAtUtc. Issuer cannot grant beyond its own rights. Each use rechecks issuing session/API token, account, permissions, and room access. Give the short ticket only to the authorized client; keep the long-lived management token on the backend.

Use Authorization: Bearer <archive ticket> for JSON. Returned short-lived resource URLs may contain rtc_archive_token; they are restricted to permitted read paths and expire. Do not forward them publicly. rtc.manage enables administrative paths; client tickets should carry minimum actions.

Query runs, timeline, and devices

The full prefix of GET .../full-exports is /api/v2/rtc/session/rooms/{roomId}/playback/recordings/{recordingId}. Tracks are separated by participantId + deviceSessionId + mediaKind; a rejoin may create another device session, which is not a hardware ID. Events contain only public chat, board, controls, and speaker activity permitted in this archive. Direct messages/attachments do not become public because a viewer is a host; missing old events should be shown as unknown, not inferred.

Media, attachments, ZIP, and full export

All read routes below share /api/v2/rtc/session/rooms/{roomId}/playback/recordings/{recordingId} and recheck that a file or attachment really belongs to this room and run.

An authorized backend queues a full export:

POST /api/v2/rtc/rooms/{roomId}/recording/continuous/{recordingId}/full-exports
Authorization: Bearer <business API token with rtc.manage>
Content-Type: application/json

{"startMilliseconds":0,"endMilliseconds":60000}

The range is in milliseconds from the run origin, with start < end inside its duration. Query the returned export job until complete. Failed post-meeting member/screen copies and exports have management retry routes .../composites/{compositeId}/retry and .../full-exports/{exportId}/retry, still requiring original tracks and grant. Full MP4 creation does not add continuous live transcoding.

Failure handling

See the UI-free archive SDK reference for Web, Android, iOS, UniApp methods and speaker-event replay.