Skip to main content
Event names follow <entity>.<action>.

Envelope

All events share the same outer envelope:
The text field is a one-line summary of the event built from data. It’s intended for two use cases:
  • Slack incoming webhooks — Slack expects { "text": "..." } at the top level, so registering a Slack webhook URL as your receiver renders each event as a chat message with no relay needed.
  • Logs / CLI tools — gives an at-a-glance description without per-type formatting.
The structured data you should integrate against still lives in data; treat text as presentation only. The headers are described in Overview → Receive events and signed per Signature verification.

Tasks

completed, failed, and cancelled all include the same rich-output fields:
  • run_id — the same id returned synchronously by POST /v2/tasks/{taskId}/run. Present only for executions started through that endpoint; use it to correlate a webhook back to the run you started. task_id is shared by every run of a task, so use run_id (or execution_id) to identify a specific run.
  • artifacts[] — task artifacts and per-session downloads, each with a name, url, and (when known) size and content_type. Empty when nothing was captured.
  • recording_url — short-lived presigned link to the primary session recording. Often missing on task.failed because the recording uploads asynchronously; subscribe to session.recording.ready if you need a stable signal that the recording is ready (then fetch it via the Recordings API).
  • session_dashboard_url — direct link into the Anchor dashboard for the underlying session.

Sessions

Batches

Both events carry the same payload shape — only the type and status field differ.

Identity