The short answer

Webhooks are how a voice platform tells your systems what happened. Calls are asynchronous and can run for minutes, so polling for completion is both wasteful and slow. Webhooks are also the integration surface most likely to be built insecurely, because an unauthenticated endpoint that accepts call events is an endpoint anyone can forge events into.

In detail

The delivery contract has to assume failure. Networks drop requests and receivers go down, so any serious sender retries with exponential backoff — which means your endpoint will receive duplicates and must be idempotent. Ordering is not guaranteed either: a completion event can arrive before the event that preceded it, so consumers should reconcile against event timestamps rather than assuming arrival order.

Verification is mandatory, not optional. A signed payload lets the receiver confirm the request came from the platform, and the signature must be computed over the raw body before any parsing or reserialisation, because a re-encoded body produces a different digest. Including a timestamp in the signed material and rejecting old requests is what prevents a captured payload from being replayed later.

The best-practice receiver does very little synchronously: verify the signature, enqueue the payload, return 200. Doing real work inline means slow processing causes sender-side timeouts and retries, which multiplies the load exactly when the system is already struggling. Logging the raw payload before processing also makes failures diagnosable after the fact.

How Rexa handles it

Rexa signs every webhook with HMAC-SHA256 over the payload, including a timestamp and a nonce, and delivers the digest in an x-webhook-signature header for the receiver to verify before trusting the request. Session lifecycle, recording completion, transfer initiation and disposition results are all delivered as webhook events rather than requiring polling.

Webhooks reference

Back to the glossary

All 53 glossary terms