When a trigger fires and a matching subscription exists, Exo sends an HTTP POST request to the subscription’s URL. This page describes the request format.Documentation Index
Fetch the complete documentation index at: https://docs.exowizz.com/llms.txt
Use this file to discover all available pages before exploring further.
Request headers
| Header | Value |
|---|---|
Content-Type | application/json |
X-Exo-Signature | HMAC-SHA256 signature: sha256= followed by the hex-encoded hash |
X-Exo-Event | Event UUID |
X-Exo-Delivery | Delivery UUID |
User-Agent | Exo-Webhook/1.0 |
Request body
The trigger that fired:
on_create, on_update, or on_delete.The resource name (e.g.
order, contact).Unique event UUID created by Exo for this trigger occurrence.
Unique delivery UUID for this specific webhook attempt.
The transformed record data, as returned by the resource’s
transform method. Date fields are formatted as ISO-8601 strings.UTC timestamp of when the event was processed, in microsecond precision:
2026-03-28T14:30:00.123456Z.Example payload
Signature verification
TheX-Exo-Signature header contains an HMAC-SHA256 hash of the raw JSON body, computed using the subscription’s secret as the key.
To verify:
- Read the raw request body (before parsing)
- Compute
sha256=+ hex-encoded HMAC-SHA256 of the body using your subscription’s secret - Compare with the
X-Exo-Signatureheader using a constant-time comparison
Delivery behavior
- Webhooks are delivered via Laravel’s queue system as background jobs
- Each delivery timeout is controlled by
exo.webhook.timeout(30 seconds by default) - If your endpoint returns a non-2xx status or times out, Exo retries based on
max_attemptsandbackoffconfiguration (or per-Resource webhook overrides) - Admins receive webhooks for all records; regular users only receive webhooks for records they own
- Inactive subscriptions (
is_active = false) are skipped during delivery