Recordings

Session recordings are planned for a later release and not yet exposed via the public API. No endpoint, webhook event, or request body field currently triggers recording today. This page describes the planned shape so customers building toward it can budget for the integration. (The W217.A parity test pins this page to "planned, not live" until the server registers the endpoint.)

Heads up: sending "record": true on POST /v1/sessions today is a no-op — the server silently strips unrecognised fields. Don't rely on recordings landing until the feature ships.

What's planned

Opt-in per session via a new record: true request body field on POST /v1/sessions. Default off.
Container: WebM (VP9 video, no audio), matching the session viewport, ~30 fps, ~500 kbps.
Retrieval via a new GET /v1/sessions/:id/recording endpoint returning a presigned R2 URL.
Webhook via a new session.recording_ready event type added to the webhook_event_type enum.
Retention tier-dependent (sketch: 7d Trial Pack, 30d Solo / API Starter, 90d Team / API Builder, 180d Agency / API Scale, custom Enterprise). Final values land with the rollout.
Redaction for sensitive inputs — also planned post-V-540.

What works today

Until recordings ship, drive your own observation pipeline from inside the session lifecycle:

Sessions API — POST /v1/sessions/:id/capture with { "kind": "screenshot" }, "dom_snapshot", or "pdf" returns inline base64 bytes you can persist on your side.
The webhook event types that fire today — session.completed, session.failed, api_key.revoked, crypto.order.paid, crypto.order.failed — plus the test.ping synthetic for endpoint verification.

How to be notified when recordings ship

Subscribe to the API changelog RSS or status-page subscriptions; the V-540 rollout will land as an entry on both, along with the new endpoint + event type appearing on /api-reference.

Support

Questions about timing or what to build toward in the meantime: [email protected].