Skip to main content
Every example below is one event for the same outbound call, for an endpoint subscribed in Set up webhooks; WhatsApp’s chat_completed is in WhatsApp events.

Event payloads

Call started event

Sent when an outbound call is registered and queued for dialling, before it connects, and when a web call starts. Inbound phone calls don’t send it. Nothing has been dialled yet, so call_sid, called_on, created_at, call_cost and the latency fields are null, and the status is registered / QUEUED. A call that connects very quickly can send a second call_started with ongoing / ACCEPTED; treat it as optional.

Call ringing and call ongoing events

Sent only for dashboard test calls, together with call_started, once the carrier accepts the dial. They don’t track real ringing or answering. The payload is smaller than call_started: no event_id, timestamp, version, call_type, numbers or cost fields. call_ongoing is identical apart from event_type.

Call completed event

Sent when a call attempt finishes, for every outcome: completed, failed, error, cancelled, forwarded, and the interim retry. When the call never connected, transcript is empty, call_duration, latency and cost are null, and sub_status carries the reason (see Status and sub-status reference).
attempts is the dial history; the top-level sub_status is the final attempt’s reason, lower-cased for failures.

Recording completed event

Sent when the recording is processed. recording_url may expire about a day after the event is sent; download the file if you need to keep it, or fetch a fresh link from Get Call Details.

Platform analysis event

Sent when Ringg’s built-in analysis completes, for every call whatever its outcome, so the top-level status and sub_status describe the call (for example failed / busy line), not the analysis. analysis_data.status is analyzed when analysis ran; a call that never connected has nothing to analyse.

Client analysis event

Sent when your Advanced Analysis completes. analysis_data holds the keys you defined; the other fields match the platform analysis event.

All processing completed event

Sent once recording, transcript and both analyses are done.

Linking retries and callbacks to the original call

A scheduled callback and a redial after voicemail are each a separate call with their own call_id and their own webhooks. Each carries parent_call_id, the call_id of the call it came from. A retry after an unanswered attempt keeps the call’s call_id; its dial history is in attempts.
  • parent_call_id is on every event type, so a child call is linkable from its call_started.
  • It is null for a call dialled directly, never absent: parent_call_id != null is a complete test for “this call came from another”.
  • Scheduled callbacks are flat: every callback points at the original call. Voicemail redials are nested: each attempt points at the one before. To find the original call, follow parent_call_id upward until it is null, and cap the number of steps.
  • The webhook has no flag to tell a callback from a voicemail redial; the call history API has the category.

Example handler

A minimal Express receiver that acknowledges first and branches on event_type:
server.js
To have an AI coding tool write the production version for your stack:

Generate a webhook handler for all_processing_completed

Open in Cursor