Skip to main content

Overview

Webhooks let Sendora push events to your server the moment they happen, instead of polling the API. Register an HTTPS endpoint, choose which events you care about, and Sendora will deliver a signed POST request within seconds.

Event catalog

Registering an endpoint

Returns:
Save the secret immediately. It is sensitive and should not be committed or returned to your frontend.

Payload shape

Every webhook POST contains the event-specific fields plus the event_type field:
The delivery record ID is available from the endpoint delivery history. The current request body does not add a universal event ID or timestamp; do not assume those fields exist unless they are part of the event payload you receive.

Event-specific payloads

booked_via is either "voice_agent" (AI booked during a call) or "operator" (manual booking in Unibox).

Verifying signatures

Sendora signs every delivery with HMAC-SHA256 using the endpoint’s secret. Always verify the signature before processing the payload. Sendora signs every delivery with HMAC-SHA256. Always verify before processing.
The signature arrives in the X-Sendora-Signature header as sha256=<hex>. Reject anything that doesn’t match. Here’s how to wire it into a request handler:
Never process a webhook payload without verifying the signature. Forged events are rejected as 401 on Sendora’s side, but your own endpoint must also verify.

Delivery flow

Delivery and retries

  • Sendora expects your endpoint to return 2xx within 30 seconds
  • If it times out or returns a non-2xx, Sendora retries after 10 seconds and 100 seconds (3 attempts total)
  • After 5 failures, the delivery is marked failed, check the delivery log

Viewing delivery history

Returns a list of recent delivery attempts with status codes, durations, and error messages.

Testing an endpoint

Send a synthetic call.completed event to verify your endpoint is reachable:
Your endpoint will receive a synthetic call.completed test payload.

Best practices

  1. Acknowledge fast, process async, return 200 immediately, then handle the event in a queue/worker
  2. Make handlers idempotent, the same delivery may be attempted more than once; use a stable event-specific identifier when one is present, or deduplicate using your own delivery ledger
  3. Always verify signatures, reject anything with an invalid or missing signature header
  4. Monitor the delivery log, set up alerts if failure rate climbs