Skip to content

Events

The nine events across the leads, conversations, messages and knowledge groups, their payloads, the resolved-versus-closed split, and the volume cap.

Nine events are delivered, across the four feature groups. Each arrives in the standard envelope described in Webhooks overview; only the data object differs. Your endpoint receives every event of the group it is wired to — branch on event.

Group leads

lead.created

Fires for every captured lead, whatever the capture path — the widget form, the agent's capture_lead action, or the public lead endpoint.

name and phone are null when the visitor did not provide them.

Group conversations

conversation.created

Fires when a new conversation thread starts — on any channel, including the omnichannel ones. It fires when the thread is created, not on every message.

conversation.resolved and conversation.closed

Two mutually exclusive end-of-life events, split by which terminal state the conversation entered:

  • conversation.resolved fires on the transition to Closed — the "handled and done" outcome (the Resolve button, or POST /api/v1/conversations/{id}/resolve). Its status is closed.
  • conversation.closed fires on the transition to Archived or Spam; its status is archived or spam, telling you which.

Both are user/agent-driven — no background job auto-closes conversations, so hearing one always means a person (or your own API call) did it. The two share one payload shape:

handoff.requested

Fires when a visitor asks for a human (or the AI escalates), whatever the entry point. Use it to page your team in real time instead of watching the inbox.

csat.received

Fires when a visitor submits a satisfaction rating, on their first rating for that conversation.

rating is 1–5. comment is null when none was written.

Group messages

message.created

Fires for every message — visitor, AI, and agent — from the platform's single message choke point. It carries metadata only, never the message content (volume and privacy); fetch the body from GET /api/v1/conversations/{id}/messages when you need it.

Note:

This event is throttled to 300 per minute per workspace. Events over the cap are dropped, not queued (the drop is counted for observability), so treat the stream as a real-time signal, not a lossless log — reconcile against GET /api/v1/conversations/{id}/messages when completeness matters.

Group knowledge

source.ingest.completed and source.ingest.failed

Fire when a knowledge source finishes processing — successfully or not — covering uploads, URL adds, crawls, edits, and reprocessing. failed fires only on the final attempt, after retries are exhausted, so one failure event means the source genuinely needs attention.

Both carry the same fields; source.ingest.failed adds error:

Where to go next

Last updated