Events reference

Webhook settings

Webhook subscriptions. The settings below are what each row carries.

Setting	Purpose
Destination	Where deliveries are sent
Event types	What triggers a delivery
Secret	Shared value the receiver uses to verify the caller
Active	Whether deliveries are attempted

Delivery behaviour

Property	Value
Semantics	At-most-once — no automatic retry; a failed delivery can be re-sent manually
Timeout	Short; a slow consumer is a failed delivery
Ordering	Not guaranteed
Failure impact	None on the originating operation, which has already committed
Recording	Real deliveries and manual re-sends are recorded with their outcome. A test-fire is not — its result is returned to you at the time and stored nowhere, so it never appears in delivery history.
Success signal	A 2xx response, which also emits an audit entry

Destination validation

Validated at five points: creation, update, test-fire, manual retry, and delivery.

The resolved address is pinned, so a destination cannot pass validation and then resolve elsewhere at delivery time. A rejected destination emits a security audit entry.

This exists because a webhook is an outbound request to an address a tenant supplies, which is otherwise a route to internal infrastructure.

Loop guard

Events about webhooks are never themselves delivered. A webhook subscribing to its own event types cannot cause a feedback storm.

Current limitations

State these plainly rather than discovering them in production:

Limitation	Consequence
No automatic retry	A failed delivery stays failed until someone re-sends it. Reconcile against the API.
Secret stored as supplied	Treat it as a shared secret, not a credential
No signature header	The secret travels in the body for comparison
No per-tenant key rotation	Rotate by updating the webhook

If your security review requires signature-based verification, raise it as a gap. It is a reasonable ask; it is not present today.

Next

• Subscribe to events

---

Last verified against commit 74cecd91 (2026-08-03)