Session Replay API
Session replay is the asynchronous twin of live co-browse. The native chat widget records the visitor’s web session (a serialized DOM snapshot plus incremental rrweb mutation events) and stores it against the conversation. A support agent plays it back later — in the inbox, with an rrweb player — to see exactly what the customer hit, after the fact rather than in real time. This page documents the operator half: listing recordings, fetching one for playback, purging one for a privacy request, and setting the capture-time masking policy. The visitor capture endpoints (how the widget uploads events) are internal to the widget runtime and not part of this surface. Base path:/api/v1/session-replay
Authentication: API key (X-API-Key) or session JWT.
Scopes & roles:
- Reads (
GET) require theconversations:readscope. - Writes —
DELETEa recording andPUTthe privacy policy — require theconversations:writescope and anowner,admin, ordeveloperrole.
A recording is keyed by its
conversationId — the conversation the session was captured against. Recordings are tenant-scoped: you only ever see the recordings captured for your own account.
List recordings
Returns the most recent recordings across your conversations as lightweight summaries — the event payloads are omitted so the list stays cheap. The inbox “Session replays” panel uses this to let an agent pick one to play back. The newest 50 recordings are returned, newest first.status is one of recording (still capturing), ended (the visitor finished or navigated away), or capped (an abuse backstop stopped capture). offloaded is true when a long session spilled past the inline head into durable storage; total_event_count and total_size_bytes describe the full recording across that storage, while event_count and size_bytes describe only the inline head. truncated is true only when the abuse backstop was hit.
Fetch a recording for playback
Returns the full rrweb event stream for one conversation. For a long recording that was offloaded, the events held in durable storage are reassembled with the inline head so the stream plays end to end. Feedsession_replay.events to an rrweb player to replay the session.
session_replay is null when the conversation exists but carries no recording. Requesting a conversation that doesn’t exist in your account returns 404 NOT_FOUND. A malformed conversationId returns 422 VALIDATION_ERROR.
Each event in events is a raw rrweb event — type (the rrweb event type), data (the opaque rrweb payload, passed straight through to the player), and timestamp (epoch milliseconds). Orbit never interprets the payload; it only stores and replays it.
Delete a recording
Removes the recording from the conversation. The conversation and its messages are untouched — only the replay is erased, including any events held in durable storage. The call is idempotent, so a privacy or right-to-erasure workflow can retry it safely. Returns404 NOT_FOUND if the conversation isn’t in your account.
Privacy masking policy
Session replay records the visitor’s DOM, which can include data the visitor typed. The masking policy decides what the capture client redacts in the visitor’s browser, before any events are uploaded — so masked content never leaves the page. The policy is account-wide and reaches new capture sessions on the next widget session bootstrap; it does not touch existing recordings or the delete path. The default posture is fail-closed: with no policy configured, every input value is masked and built-in PII heuristics are on. You must explicitly relax masking.
Each selector entry is a single CSS selector, trimmed and non-empty (max 200 characters); up to 200 entries are allowed in each selector list.
Get the policy
Update the policy
422 VALIDATION_ERROR.
See also
- Conversations API — the threads recordings attach to
- Inbox API — where agents play recordings back
- Error codes