Webhooks
Overview
Voice API webhooks provide real-time notifications about events occurring during call processing. These webhooks enable your application to respond to various telephony events with custom business logic.
Webhook Configuration
Webhooks can be configured in three different ways:
- Connection Webhook Config: Default webhook configuration tied to a connection.
- Custom Webhook Config: Webhook settings specified per command.
- Events Webhook Config: Advanced configuration allowing different URLs for different event types.
Configuration Parameters
The connection level configuration contains the following configuration parameters:
webhook_url
: Primary destination for webhook deliverywebhook_url_method
: HTTP method for webhook requests (default: "POST")failover_url
: Secondary destination if primary failswebhook_api_version
: API version for webhook format ("1" or "2")webhook_timeout_seconds
: Timeout for webhook requests
HTTP Methods and Headers
HTTP Methods
- Webhooks are sent using either
POST
orGET
methods as specified in thewebhook_url_method
parameter. - By default, all webhooks are sent using the
POST
method if not otherwise specified. - For
POST
requests, the webhook payload is sent in the request body as JSON. - For
GET
requests, the webhook payload is encoded in the URL query parameters.
HTTP Headers
Webhook requests include the following headers:
Content-Type: application/json
(for POST requests)User-Agent: telnyx-webhooks
Telnyx-Signature-Ed25519
: Webhook signature for verificationTelnyx-Timestamp
: Unix timestamp when the webhook was generated
Webhook Parameters
Webhook requests contain the following parameters:
Common Parameters
All webhook events include these common parameters:
Parameter | Type | Description |
---|---|---|
id | String | Unique identifier for the webhook event |
record_type | String | Always "event" for webhooks |
event_type | String | Type of event (see event types tables) |
occurred_at | String | ISO-8601 timestamp when the event was created |
payload | Object | Contains event-specific data |
Event-Specific Payload Parameters
The payload
object contains parameters specific to each event type, but common fields include:
Parameter | Type | Description |
---|---|---|
call_control_id | String | Unique identifier for the call control session |
call_leg_id | String | Unique identifier for the specific call leg |
call_session_id | String | Unique identifier for the entire call session |
connection_id | String | Identifier for the connection used |
from | String | Calling party phone number or address |
to | String | Called party phone number or address |
Webhook Signature Verification
For security, all webhooks are signed using ED25519. More information can be found under the link
Webhook Event Types
All expected webhooks are specified in the documentation for each of the Voice REST endpoint i.e. Make a new call endpoint
Webhook Delivery Process
- When an event occurs, the system checks if webhooks are enabled for the connection
- The system determines which webhook configuration to use (connection, custom, or event-specific)
- The webhook payload is constructed with event data
- The system attempts to deliver the webhook to the configured URL
- If delivery fails and a failover URL is configured, the system attempts delivery to the failover URL
- The system logs the webhook delivery attempt
Response Codes
The following HTTP response codes determine if a webhook delivery is successful:
- 2xx: Success, webhook received
- 3xx: Redirect (system will follow up to 3 redirects)
- 4xx: Client error (no retry, except for 408 Request Timeout and 429 Too Many Requests)
- 5xx: Server error (will trigger retry mechanism)
Best Practices
- Implement idempotency: Webhooks may be delivered more than once in rare cases
- Respond quickly: Return 2xx HTTP responses promptly (within 10 seconds) to acknowledge receipt
- Use webhooks for event notifications only: Do not rely on webhooks for critical control flow
- Implement signature verification: Always validate webhook authenticity using the provided signature
- Handle webhook timeouts: Configure reasonable timeout values
- Monitor webhook deliveries: Track failed webhooks and implement alerting for critical events
- Create a webhook testing environment: Test your webhook handlers before deploying to production
- Implement graceful degradation: Have fallback mechanisms if webhooks are delayed or missing