No unsigned fallback
A secret-service failure causes delivery to retry; it never causes an unsigned request to leave.
Security
Boundaries that hold from send to embed.
Sign every delivery, protect reserved headers, scope customer portal sessions, rotate secrets with controlled overlap, and restrict where the portal can be embedded.
For platform and security teams reviewing webhook delivery and customer-facing integration controls.
Live product model
Delivery headers
webhook-id msg_01J…
webhook-timestamp 1783684800
webhook-signature v1,••••••
Secret versions
Version 2active
Version 1overlap · 23h
portal · customer scoped
Why it matters
Security lives in the workflow, not a checklist.
Security behavior is part of the delivery and portal workflow, not a separate checklist applied after launch.
The other half of that signature runs on code you do not control: webhook signature verification, end to end.
- Per-attempt signed body
- Protected webhook headers
- Exact allowed-origin validation
How it works
Signed, scoped, and auditable by default.
- 01
Sign every request
Create the signature over the message ID, attempt timestamp, and exact body.
- 02
Protect the envelope
Prevent endpoint custom headers from replacing identity, signature, or content headers.
- 03
Rotate deliberately
Issue a new secret and optionally keep the previous version signing through a defined overlap.
- 04
Constrain the portal
Scope tokens to one customer and environment and allow embedding only from approved origins.
What you can do
Controls you can point to in review.
Secret version overlap
Multiple eligible signatures allow receivers to move to a new secret without a single-instant cutover.
Tenant-scoped access
Cross-customer endpoint, delivery, and secret access returns no resource.
Read-only sessions
Preview sessions block configuration changes, secret access, and replay.
From schema to delivery