Skip to content

Webhooks

Teler delivers asynchronous events to your HTTPS endpoint as signed POST requests. Use webhooks for state changes you can’t afford to poll for: call lifecycle, stream lifecycle, and recording availability.

PropertyValue
TransportHTTPS POST, JSON body
Timeout5 seconds for your response
SuccessAny 2xx response
Retry policyUp to 5 attempts, exponential backoff (immediate to ~30 min)
OrderingBest-effort per call_id. Use timestamps to reorder.
IdempotencyEach event has a unique ID. Dedupe on receive.
SigningHMAC-SHA256, see Signing & verification

Webhooks are sent to:

  • The Call Status URL on a Voice App, for inbound calls.
  • The status_callback_url passed to calls.create(), for outbound calls.
  • The Call Status URL on a SIP Trunk, for trunk-routed calls.

Your endpoint must be HTTPS and reachable from the public internet.

Your endpoint must return 2xx within 5 seconds. If you do real work inline, such as database writes, downstream API calls, and slow integrations, you risk timeouts and unnecessary retries.

Every production webhook handler should follow the same shape:

1. Verify the signature
2. Acknowledge with 200 OK
3. Enqueue for async processing

Non-2xx responses, timeouts, and connection errors are retried with exponential backoff:

AttemptDelay (approx)
1immediate
2+5 s
3+30 s
4+5 min
5+30 min

After 5 failed attempts the event is marked failed (not dropped). Failed events remain visible in the dashboard’s webhook log and can be redelivered for up to 30 days.

Events for the same call_id are dispatched in chronological order, but network re-ordering can deliver them out of sequence to your endpoint. Don’t trust arrival order. Use the timestamps inside the event payload (occurred_at on the envelope, answered_at, ended_at, etc.) to reconstruct the lifecycle.