Events at a glance
Delivery semantics
| Property | Value |
|---|---|
| Semantics | At-most-once — no automatic retry |
| Timeout | Short; a slow consumer is a failed delivery |
| Ordering | Not guaranteed |
| Failure impact | None — the change already committed |
| Recording | Real deliveries and manual re-sends are recorded; a test-fire is not |
A failed delivery can be re-sent manually, but nothing re-sends it for you.
What a correct consumer does
With at-most-once delivery, a consumer that assumes it sees every event will eventually be wrong — and will not know it.
Treat webhooks as a low-latency notification that something changed, and reconcile against the API for correctness. This is the single most consequential thing to get right.
- Acknowledge fast; do the work asynchronously.
- Do not assume ordering.
- Reconcile periodically.
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.
This exists because a webhook is an outbound request to an address a tenant supplies — otherwise a route to internal infrastructure. A rejected destination emits a security audit entry.
Loop guard
Events about webhooks are never themselves delivered, so a webhook subscribing to its own event types cannot cause a feedback storm.
Current limitations
Stated plainly rather than discovered in production:
| Limitation | Consequence |
|---|---|
| No automatic retry | A failed delivery stays failed until re-sent |
| Secret stored as supplied | A shared secret, not a credential |
| No signature header | The secret travels in the body for comparison |
If your security review requires signature-based verification, raise it as a gap. It is reasonable; it is not present today.
Discover event types
Query the platform rather than working from a written list.
Next
Last verified against commit 1e1de1ad (2026-08-03)