URGENT: Missing Webhook Data for Certain Call Sess...
# supportk
krishna chaitanya
05/04/2026, 11:39 AMWe’re seeing intermittent cases where completed calls don’t trigger webhook events.
Example call id: 019df2b4-0084-7bbd-a6e9-a6bb6220be76 — no webhook received after call end.
Could you confirm:
Possible reasons for missing webhook delivery
Any known conditions where webhooks are skipped
How to ensure reliable delivery (retries, configs, etc.)
p
Praise Heritage Abayomi
05/04/2026, 1:22 PMHi! Yes, I can help with this. From my experience, intermittent missing webhooks usually happen because the delivery failed silently due to timeout/response handling, the call terminated unexpectedly, or the event pipeline didn’t fully complete after the call ended.
I can help investigate the specific call ID, review the webhook flow, and identify why the call.completed event wasn’t received. I can also help you make the delivery more reliable with proper retry handling and webhook validation.
@krishna chaitanya
k
krishna chaitanya
05/04/2026, 3:35 PMThanks for the response.
We need a concrete solution since this is a scaling platform.
Example Call ID: 019df2b4-0084-7bbd-a6e9-a6bb6220be76
Please confirm:
Do you support webhook retries? (policy, attempts, intervals)
Is there a fallback (API/polling) to fetch missed events?
What ack/response requirements ensure delivery isn’t dropped?
Any timeouts or limits that could cause silent failures?
We need a reliable, production-safe approach to guarantee event delivery.
krishna chaitanya
05/06/2026, 4:21 AMHi @Praise Heritage Abayomi , this is urgent—could you please confirm webhook retry policy, fallback options, and ack/timeout requirements for reliable delivery? We’re blocked on production readiness without this.
s
Shaunak
05/21/2026, 5:19 AMHi, we apologise for the delay. We'll soon get back to you on this
Shaunak
05/21/2026, 6:08 AMHi,
Thanks for sharing the call ID - that made it straightforward to investigate.
What happened on call 019df2b4
This call ended with reason customer-did-not-answer and never actually started - no media was exchanged. Vapi does not send end-of-call-report webhooks for calls that never establish a media connection. This is expected behavior, not a delivery failure.
Shaunak
05/21/2026, 6:08 AMWhen webhooks are skipped
Beyond unanswered calls, webhooks are also skipped if no serverUrl is configured at any level (tool, assistant, phone number, or org), if end-of-call-report is excluded from your serverMessages array, or if there is an LLM timeout during the cleanup phase.
Shaunak
05/21/2026, 6:08 AMRetry policy
There are currently no automatic retries. Each webhook attempt has a 20-second timeout, and if your endpoint does not respond with a 2xx within that window the event is logged and dropped. Your endpoint response body is ignored - only the status code matters.
Shaunak
05/21/2026, 6:08 AMRecommended approach for production reliability
To catch unanswered and failed calls, add status-update to your serverMessages array - this event is fired for all calls including ones that never start:
"serverMessages": ["end-of-call-report", "status-update"]
For guaranteed delivery, implement a polling fallback using GET /call/:id as a safety net. Wait around 60-120 seconds after call creation before polling to avoid race conditions. Use the call ID as an idempotency key on your end to handle any duplicates.
On your endpoint side, respond HTTP 200 within 5 seconds and process the payload asynchronously to avoid timeouts.
Shaunak
05/21/2026, 6:08 AMLet us know if you have any other questions.