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, socall_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 withcall_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-levelstatus 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 owncall_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_idis on every event type, so a child call is linkable from itscall_started.- It is
nullfor a call dialled directly, never absent:parent_call_id != nullis 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_idupward until it isnull, 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 onevent_type:
server.js
Generate a webhook handler for all_processing_completed