Before you register: hostname allowlist
Webhook destinations are gated by a per-organization hostname allowlist. This is a defense-in-depth check on top of Svix’s own URL validation — it prevents a leaked API key from being turned into an SSRF relay via Svix. Allowlist rules:- Scheme must be
https://. - Exact match:
webhook.sitepermits onlywebhook.site. - Wildcard subdomain:
*.example.compermitsa.example.com,foo.bar.example.com, but not the apexexample.com. - Matching is case-insensitive and uses punycode form.
Register an endpoint
secret starting with whsec_. Save it immediately — it is returned only at creation time and is required for signature verification. There is no rotation endpoint today; if you lose or leak it, delete the endpoint and create a new one.
Omit events (or pass []) to subscribe to every event type.
Event types
The
deal.scoring.* events are declared in the schema so SDK types remain stable, but the publisher isn’t wired up yet — subscribing to them today produces no deliveries. They’ll be enabled in a future release.
Full payload schemas are in the API Reference tab.
Signature verification
Every delivery has three headers:svix-id— unique delivery ID, stable across retriessvix-timestamp— Unix seconds at send timesvix-signature— HMAC signature(s). During secret rotation, multiple space-separated signatures are sent so subscribers have a verification window; any matching one proves authenticity.
verify — not a re-serialized JSON object.
Delivery semantics
- Respond with any
2xxstatus to acknowledge; non-2xxresponses or network failures trigger retries with exponential backoff. - The
svix-idheader is stable across retries — store received IDs and skip already-processed events to make your handler idempotent. - Retry schedule, timeout, and retention are handled by Svix. See Svix delivery documentation for specifics.
List and delete endpoints
ep_. Deleting an endpoint is immediate — in-flight deliveries still complete, but no new events are sent.