Webhooks
Voicebip delivers real-time events to your webhook URL via HTTP POST with HMAC-SHA256 signatures.
Event Types
Voice
SMS & WhatsApp
call.barge_in, call.idle_silence, call.quality, and call.quality_degraded can be high-volume on busy agents. If you don’t process them, register a webhook endpoint that filters them out at the edge — every delivered event still counts against your endpoint’s processing capacity.
Internal NATS Subjects (Not Delivered to Webhooks)
Voicebip’s internal pipelines publish additional subjects that are not forwarded to your webhook URL today. They are documented here so you can recognise them in support tickets and dashboard activity feeds, and so the boundary between “webhook events” and “internal pipeline events” is explicit.
If you have a use case for receiving any of these as webhooks, open an issue — most can be surfaced behind a feature flag.
Payload Format
Every webhook delivery is a JSON object with a common outer envelope and an
event-type-specific payload field.
Envelope
call.initiated
Published when a call connects and media is flowing. Phone numbers are always E.164; Nigerian DIDs use the +234 country code.
call.transcription
Published on every final STT transcript — once per caller utterance. The
turn_id matches the turn_id field in the BYOM webhook request for the
same utterance.
call.completed
Published when the call ends. Contains the full transcript and
AI-mode metadata. Check ai_mode to confirm whether the call was handled
by your BYOM webhook ("byom") or a hosted provider.
BYOM agents: lifecycle events (call.initiated, call.transcription,
call.completed) are delivered to the same webhook_url as the per-turn
BYOM requests — they are not separate URLs. Check for an event_type field
in the request body to tell them apart: lifecycle events carry event_type
and expect {"received": true}; BYOM turns do not carry event_type and
expect a BYOMVoiceWebhookResponse. See the BYOM guide for
the turn request/response schema and HMAC verification.
Signature Verification
Every webhook delivery includes the following headers:
The signed payload is "{timestamp}.{body}" — the Unix timestamp string, a literal ., then the raw request body. This lets you reject replayed deliveries by checking the timestamp age.
Retry Policy
Failed webhook deliveries are retried with exponential backoff:
A delivery is considered failed if your endpoint returns a non-2xx status code or times out after 10 seconds.
Testing Webhooks
POST /v1/webhooks/test delivers a realistic mock payload to any URL with a
valid HMAC signature — no real call or message is needed.
The mock payload always includes:
- Valid Nigerian E.164 phone numbers (+2348031234567, +2349012345678)
- Realistic conversation history
- A valid
X-Voicebip-SignatureHMAC header so your verification code runs
Supported event_type values: call.initiated, call.transcription,
call.completed, call.barge_in, call.idle_silence, call.quality,
call.quality_degraded, message.received, message.sent,
message.delivered, message.failed.
Testing BYOM Routing End-to-End
The fastest way to verify your BYOM webhook before a live call:
- Expose a local endpoint with ngrok:
ngrok http 8080 - Update your agent’s
webhook_urlto the ngrok URL - Use a
pk_test_API key — sandbox mode synthesizes the full BYOM turn without a real SIP call or billing charge - Fire a
call.transcriptiontest event to your events endpoint to see what the event stream looks like alongside the BYOM turn requests:
- Make a sandbox test call (or use the Dashboard’s “Test call” button) and
watch both channels: BYOM turn POSTs arrive at
webhook_url, lifecycle events arrive at the registered events endpoint.
Signing Secret Rotation
When you rotate your workspace’s signing secret, Voicebip sends both the new and old signatures during a 24-hour grace period:
X-Voicebip-Signature— signature using the new secretX-Voicebip-Signature-Previous— signature using the old secret (present during 24h grace window only)
Your verification code should accept either signature during rotation to avoid rejecting valid deliveries.
Multiple Webhook Endpoints (Fan-Out)
Each agent supports multiple webhook URLs. When a matching event fires, the platform delivers the same payload to every active endpoint independently — each has its own attempt counter, retry queue, and delivery status. One slow or failing endpoint does not affect delivery to the others.
Register an Endpoint
Response:
List Endpoints
Pause / Resume an Endpoint
Toggle the active flag without deleting the endpoint:
Delete an Endpoint
The legacy webhook_url field on the agent object is the backward-compatible single-endpoint configuration. It remains the fallback destination when no rows exist in webhook_endpoints. Both mechanisms can coexist — if an agent has a webhook_url and registered endpoints, the consumer uses the registered endpoints and treats webhook_url as a belt-and-braces fallback only when no active endpoint rows are found.
Webhook Delivery Log
Monitor recent webhook deliveries via the API or the Voicebip Dashboard.
List Deliveries
Each delivery entry includes the event type and payload, HTTP status code from your endpoint, retry attempt count, and next retry timestamp if applicable.
Get a Single Delivery
Replay Failed Deliveries (DLQ)
If your endpoint was down during the retry window, you can replay failed deliveries from the dead-letter queue:
Replayed deliveries restart the full 7-attempt retry sequence from attempt 1.