Use meeting token to start video recording automatically

[zachm-vapi]

Use meeting token to start video recording automatically

Linear: VAPICS-1216

Context

Customers with weak network connections sometimes end calls with no videoRecordingUrl because the client-initiated startRecording() request never reaches Daily. Per Daily support's recommendation, the backend now creates a meeting token with start_cloud_recording: true when video recording is enabled and returns it on the web call as call.transport.callToken. Joining with that token makes Daily start the cloud recording automatically, which is more reliable.

This relates to #168, which allows the client to retry the recording if it fails. Both changes are needed, because the recording can still fail even when started via a token.

Changes

SDK (vapi.ts)

• start() reads call.transport.callToken from the create-web-call response and joins the Daily room with it. When a token is present, the client-side startRecording() call is skipped because it will start automatically.
• reconnect() does the same; the WebCall param type gains an optional transport.callToken field, which is picked up automatically by apps that pass back the Call object from start().
• The recording-started listener that sends the say-first-message control is now registered before join() in both methods. On the token path the recording can start while join is still in flight, and a listener registered after join could miss the event (and never trigger the assistant's greeting).
• The video-recording-setup progress event reports metadata.action: 'auto-started-via-meeting-token' on the token path so the two flows are distinguishable in telemetry.

Example app — Updated so that we can test the video recording and reconnect workflows. Video recording is now toggleable via a checkbox, a local camera preview (with recording indicator) shows when the camera is live, the stored call data includes transport so reconnects use the token, and Stop (leave) / End are now separate buttons (previously the stop button would always end the call, so it wasn't possible to reconnect).

Backward compatibility

• No token (old servers, ZDR orgs, token-creation failure): join() gets no token key and the SDK falls back to client-initiated startRecording() — identical to the old flow.
• Old SDKs + new server: ignore the token field and keep client-initiated recording; the backend still sets room-level enable_recording for exactly this case.
• Recording stop semantics are unchanged. The recording is still stopped manually when the client leaves because the meeting token only starts it automatically.
• Progress-event ordering: on the token path, the video-recording-started progress event can occasionally be emitted before video-recording-setup: completed, because the recording may start while join() is still in flight (on the old client-initiated path, setup always preceded started). Consumers should not assume the ordering; each event carries a timestamp and, on the token path, a metadata.action discriminator for disambiguation.

Testing

Used the example app to manually verify that video recording works, including when the caller stops and reconnects to the call. Tested against both the Vapi prod server (before the backend change), and my local test server (including the backend change), to verify that we still fall back to the old behavior when a callToken isn't provided.

[zachm-vapi]

• Use meeting token to start video recording automatically #171 👈 (View in Graphite)
• Make it possible to retry the video recording if it fails #168
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[zachm-vapi]

Merge activity

• Aug 20, 9:51 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Aug 20, 9:53 PM UTC: Graphite rebased this pull request as part of a merge.
• Aug 20, 9:53 PM UTC: @zachm-vapi merged this pull request with Graphite.