Intro
Webhooks are how services notify each other of events. At their core they are just a POST request to a pre-determined endpoint. The endpoint can be whatever you want, and you can just add them from the UI. You normally use one endpoint per service, and that endpoint listens to all of the event types. For example, if you receive webhooks from Acme Inc., you can structure your URL like: https://www.example.com/acme/webhooks/. The way to indicate that a webhook has been processed is by returning a 2xx (status code 200-299) response to the webhook message within a reasonable time-frame (15s). It’s also important to disable CSRF protection for this endpoint if the framework you use enables them by default. Another important aspect of handling webhooks is to verify the signature and timestamp when processing them. You can learn more about it in the signature verification section.Adding an Endpoint
In order to start listening to messages, you will need to configure your endpoints. Adding an endpoint is as simple as providing a URL that you control. In the Settings go to the API & Webhooks section and click on “Configure” to get to the webhook portal.

Events
We support the following webhook events:call_ended
: Triggered when a call is completed and analyzedcontact_status_changed
: Triggered when a contact’s status changes
Call Ended Event
When a call is completed and analyzed, we’ll send a webhook with detailed information about the call, including the transcript, analysis results, and complete contact information (in the same format as the/v1/get-contact/{contactId}
API endpoint).
Call Statuses
A call can have the following statuses:
COMPLETED
: A conversation occurred with the contactANSWERED
: A call occurred but another attempt will be made to reach the contactNOT_REACHED
: We weren’t able to reach the contactVOICEMAIL
: We got the voicemail of the contactERROR
: An error occurred in the call
Example Payload
Contact Status Changed Event
The contact status changed event helps you track the progress of contacts through your calling campaign. Each contact moves through different states as they are processed by the system.Contact Statuses
Contacts can have the following statuses:new
: Contact has not been called yetpending
: Contact is in dialer and we are trying to reach themclosed
: Dialer was exhausted and we are not trying to call them anymorereached
: Contact was reached and had a conversation. We are not trying to call them anymore
Example Payload
Verifying Signatures
Webhook signatures let you verify that webhook messages are actually sent by us and not a malicious actor. Verifying webhooks is optional but recommended. For a more detailed explanation, check out this article on why you should verify webhooks. Our webhook partner Svix offers a set of useful libraries that make verifying webhooks very simple. Here is a an example using Javascript:Retries
Automatic Retries
We attempts to deliver each webhook message based on a retry schedule with exponential backoff. The schedule Each message is attempted based on the following schedule, where each period is started following the failure of the preceding attempt:- Immediately
- 5 seconds
- 5 minutes
- 30 minutes
- 2 hours
- 5 hours
- 10 hours
- 10 hours (in addition to the previous)