Skip to main content
A webhook subscription tells Vobiz to POST messaging events to a URL you own: delivery status changes, inbound messages and broadcast progress. Each delivery is signed with a secret you choose, so your server can confirm it came from Vobiz. You manage subscriptions through the /webhooks endpoints or in the console under SMS & RCS → Webhooks.
Messaging webhooks use their own headers and signing scheme, described on this page. Voice callbacks (call status, VobizXML requests) use the X-Vobiz-Signature-* headers described in Validating callbacks. Keep the two verifiers separate.

Events

Subscribe to any of these event names. The default subscription, used when you omit events, is message.received, message.delivered and message.failed. Vobiz delivers an event to a subscription only when that subscription is active and its events list contains the exact event name.

Manage subscriptions

Create

POST /webhooks with url (required), secret and events. Use an HTTPS URL and a long random secret.
The response is 201 with the subscription:
The API returns secret in clear text on create, list and get. Anyone who can read your subscriptions can forge signed deliveries, so protect your Auth ID and Auth Token as you would the secret itself, and rotate the secret with PUT if it leaks.

List, get, update, delete

Set active: false to pause deliveries without losing the subscription, for example during a deployment.
cURL

The delivery request

Vobiz sends an HTTP POST to your url with a JSON body and these headers: The body is always the same envelope:

Delivery-status payload

For message.status, message.delivered and message.failed, data describes the message and its new state:
On a failure, the inner data also carries the reason:
errorCode and errorMessage are present only when the network reported them. Look the message up with GET /messages/{id} for the full record and its statusHistory.

Responding

  • Return any 2xx status within 30 seconds. A 3xx, 4xx, 5xx or a timeout counts as a failed delivery.
  • Vobiz redelivers a failed event until your endpoint accepts it. Because a slow response can also trigger a redelivery, treat every delivery as possibly repeated and de-duplicate on X-Webhook-ID.
  • Verify the signature first, acknowledge, then do your own processing asynchronously.

Verify the signature

Compute HMAC-SHA256 over the raw request bytes with your secret, hex-encode it in lower case, and compare it to X-Webhook-Signature with a constant-time comparison. Do not re-serialise the parsed JSON; whitespace changes break the digest.
To test locally, create a subscription pointing at a tunnel URL, send yourself a message with POST /messages, and log the headers and body you receive. Replace the in-memory seen set with your database or cache before going to production.

Webhooks or WebSocket?

Webhooks are the durable path: events are redelivered until your backend accepts them, and they work without a persistent connection. The WebSocket is for live dashboards and consoles that need updates on screen while they are open. Use both when you need both.

Next steps

Webhook endpoints

Full subscription schema.

Conversations

Threads built from the inbound messages your webhook receives.

Before you go live

Messaging numbers

Get a number that sends and receives.

Compliance overview

Register before production traffic.