Skip to main content
Call events track a call through its whole life. Every event for one call carries the same call_uuid, so you can join them into a single timeline: call.startedcall.ringingcall.answeredcall.held / call.resumedcall.endedcall.recording_ready One more event sits outside that sequence: call.tags_modified fires whenever tags are added to or removed from a call, during the call or long after it ended. These are account-level webhooks, delivered to the endpoints you register under Account → Webhooks. See the overview. All examples on this page show the full request body, including the envelope. Fields with empty values are omitted from payloads rather than sent as null. The one exception is tags[].name on call.tags_modified, which is explicitly nullable; accept null there. Fields shown in bold are always present. A bold field nested inside an optional object is always present whenever that object is. Everything else is optional.

Common objects

Two objects appear across call events.

The contact object

Each entry in contacts is a contact from your account that matches the call. Every field except id is included only when it has a value.

The user object

The user field identifies the CloudTalk user handling the call. It is omitted (never null) when no user is assigned yet. Every field except id is included only when it has a value. The same object appears wherever a user is referenced on other events: favorite_user on contacts, user on messages, and callers[].user on Conversation Intelligence events.

Number types

Every number object (internal_number on call and message events, default_outbound_number.number and associated_numbers[] on user events) carries a number_type with one of these values: New values may be added over time; handle unknown values gracefully rather than failing.

Large contact sets

A call can match many contacts, and a number shared by many contacts does so routinely. To keep every payload deliverable, the first 10 matching contacts are included in full; any beyond that are included as { "id": "44211" } only, carrying the id and nothing else, and the event carries "contacts_truncated": true. Fetch the details of the id-only entries from the Contacts API when you need them. Every event that carries contacts also carries contacts_total, the number of contacts that matched before any trimming. Compare it with the length of contacts:
  • Equal: every matched contact is present, some as id only. You are missing detail, not contacts.
  • Greater: the matched set was so large that trailing ids had to be dropped to keep the event deliverable. You are missing contacts entirely and cannot tell which; fetch the call’s contacts from the API instead.
One more case sets contacts_truncated at any list size: a single very large contact record (many custom fields, phone numbers or emails) is reduced to { "id" } when the set would otherwise exceed its size budget. When nothing was trimmed, contacts_truncated is absent. This applies to every call event that carries contacts: call.started, call.ringing, call.answered, call.ended, and call.recording_ready.

call.started

Fires the moment a call begins: as soon as an inbound call reaches your account or an outbound call is placed, before anyone picks up. Use it to pop the caller’s record in your CRM, start tracking a live call on a wallboard, or kick off any workflow that needs to know a conversation is underway.
Example

call.ringing

Fires when a call starts ringing on a specific user’s phone or app. Use it to alert the right person in your own tools, show who is being called on a live dashboard, or prepare a screen pop before the user picks up. The payload has the same shape as call.started; user identifies the user being rung.
Example
A call that rings several users in sequence or in parallel can produce more than one call.ringing event. Each identifies the user being rung.

call.answered

Fires when a call is picked up and the conversation begins. Use it to log pickup times, start measuring talk time, or update a live view of ongoing conversations. The payload has the same shape as call.started; user identifies the user who answered.
Example

call.held

Fires when a call is placed on hold. Use it to measure hold time, keep live dashboards accurate, or trigger reminders when a hold runs long. Hold events carry the call reference and, when the hold is attributable to one, the user. Join on call_uuid with the other lifecycle events for contact and number context.
Example

call.resumed

Fires when a call is taken off hold. Pair it with call.held to calculate hold durations, or use it to keep live call status accurate. The payload has the same shape as call.held.
Example
When computing hold durations, tolerate unpaired events: a call.resumed can arrive without a preceding call.held, and delivery order is not guaranteed. Pair on call_uuid and order by occurred_at.

call.ended

Fires when a call finishes and its final details have been processed: direction, the numbers involved, start time, durations, whether the call was recorded, and whether it went to voicemail, together with the matched contacts and the user who handled it. Use it to log completed calls in your CRM or helpdesk, trigger post-call follow-ups, or feed reporting the moment a call wraps up.
If the call was recorded, the recording is announced separately (sometimes minutes later) by call.recording_ready. Don’t expect recording details on call.ended.
Example

call.recording_ready

Fires when a call’s recording (including voicemail messages) has been stored and is available. This is an asynchronous event: it fires after call.ended, sometimes minutes later. Use it to kick off post-call workflows such as QA review, coaching, or attaching the recording reference to your CRM record of the call. It fires for every recorded call. The only prerequisite is that call recording is switched on for that direction in your account settings; transcription and Conversation Intelligence are not required.
The event does not include a download link. Use call_id with the Recording media endpoint to retrieve the recording with your API credentials.
Example
Voicemail recordings arrive as regular call.recording_ready events. To tell whether a recording is a voicemail, check is_voicemail on the matching call.ended event (same call_id).

call.tags_modified

Fires when tags are added to or removed from a call: by a user during or after the call, or by an automation. Use it to mirror call tagging into your CRM or ticketing system, trigger follow-ups when a specific tag is applied, or drive reporting on how calls are categorised. Each event describes one change: the direction (added or removed) and the tags involved. It is a delta, not the call’s full tag list; to know a call’s current tags, fetch the call from the API rather than reconstructing them from a sequence of events.
Example
Unlike the other call events, call.tags_modified carries no contacts or user. For that context, join on call_uuid with the call.started or call.ended event you stored, or fetch the call from the API.