Call Updates

Sends real-time HTTP notifications to your endpoint as a call moves through its lifecycle. Use it to track call state in your system at the exact moment each transition happens.

Delivery

• Method: POST
• Content-Type: application/json
• Request timeout: 10 seconds. If your endpoint does not respond in 10s, the attempt is treated as failed and retried.

Status values

A single event type call.updated is emitted with a status field indicating which transition occurred.

status	Emitted when
initiated	Dialing to the number has been confirmed. The call record has been created and dialing was sent to telephony.
in-progress	The call was answered and the conversation is in progress.

More statuses may be added in the future. Your handler should ignore unknown status values instead of rejecting the request.

Payload

All requests share the same JSON structure. Only status and timestamp change between events.

{
  "event": "call.updated",
  "status": "initiated",
  "timestamp": "2026-04-17T14:32:08.512Z",
  "call": {
    "id": "cHYqKdGz25Rq"
  },
  "agent": {
    "name": "Sofia Sales Agent",
    "slug": "sofia-sales-agent"
  },
  "customer": {
    "name": "Jane Doe",
    "phoneNumber": "+15551234567"
  }
}

Main fields

Field	Type	Description
event	string	Always "call.updated".
status	string	"initiated" or "in-progress".
timestamp	string	ISO-8601 UTC timestamp when the transition occurred.
call.id	string	Unique call ID, consistent across all webhooks for the same call.
agent.name	string	Human-readable agent name.
agent.slug	string	Stable agent slug.
customer.name	string	Optional. Present when name was provided when creating the call.
customer.phoneNumber	string	Destination phone number in E.164 format.

Event order

For a typical call, events usually arrive in this order:

1. call.updated with status: "initiated"
2. call.updated with status: "in-progress" (only if call is answered)
3. Existing End of Call / End of Session events

Because events are delivered independently and retries can reorder events in rare failure scenarios, do not rely on strict ordering.

Responding to events

Return any HTTP 2xx status code to acknowledge receipt. Response body is ignored.

Any of the following is treated as failure and triggers a retry:

• 3xx, 4xx, or 5xx response
• Network error (connection refused, DNS failure, TLS error)
• No response within 10-second timeout

Your endpoint must be idempotent. Since non-2xx responses are retried, the same event may be delivered multiple times. Deduplicate using call.id + status.

Respond well under 10 seconds—ideally acknowledge immediately (for example by queueing the event) and do heavy processing asynchronously.

Retry policy

Failed deliveries are retried automatically with exponential backoff:

Attempt	Delay after previous attempt
1	— (initial delivery)
2	2 seconds
3	4 seconds
4	8 seconds
5	16 seconds
6	32 seconds

After six attempts the event is dropped and won't be resent. If your endpoint was down longer than the retry window, reconcile state using the End of Call webhook or API instead of waiting for redelivery.