Skip to main content
We POST compact WhatsApp calling events when a contact is asked to allow calls, answers that request, or a WhatsApp call starts. This is how you listen for “they allowed the call” without polling.
Automations — use the WhatsApp voice event trigger. That binds a dedicated webhook and will not overwrite your New conversation flow.Custom backends — events are also POSTed to the assistant’s conversation webhook URL (the same URL used for new-conversation notifications). Filter incoming POSTs on "event": "whatsapp_voice".
Completed WhatsApp calls still use the post-call webhook. Inbound WhatsApp calls that your assistant answers also follow the assistant’s inbound webhook, if you have one.

​
Event types

​
Payload

Every voice event is a small JSON object. It does not include provider IDs, trunks, recordings, transcripts, or costs.
​
string
Always whatsapp_voice
​
string
One of the event types above
​
integer
WhatsApp sender that owns the chat
​
string
Customer number in E.164
​
string
Conversation UUID, or null
​
string
Assistant UUID
​
string
Current permission status: pending, granted, rejected, revoked, expired, or null
​
string
When granted consent ends, or null
​
boolean
Whether you may place a WhatsApp call right now
​
integer
Present only on voice_call. Dashboard call id.
​
string
Present only on voice_call: whatsapp_outbound or whatsapp_inbound

​
Typical automation

  1. Customer replies to your template (24-hour window opens)
  2. You request permission
  3. Your server receives call_permission_granted
  4. You place the call
  5. You receive voice_call, then later the post-call webhook
If you never receive call_permission_granted, the customer declined, ignored the card, or the ask never delivered. Check Get call permission and WhatsApp Calling.

​
Delivery

  • POST JSON, 10 second timeout, up to 3 retries
  • Respond with HTTP 2xx so we do not retry
  • Ignore events whose event is not whatsapp_voice if you also use this URL for new conversations