Delivery
Once an endpoint is registered, the platform delivers each subscribed event to it as an HTTP POST. This page covers what counts as success, how retries work, what to assume about ordering, and how to recover a delivery that failed.
What your endpoint must return
Respond with any 2xx status code, fast. A 2xx is the platform's signal that you've taken responsibility for the event; it stops retrying.
- Any non-
2xxstatus, a connection error, or a timeout counts as a failed delivery and is retried. - Acknowledge first, work later. Verify the signature, record the event, return
2xx— then do slow processing out of band. If you do heavy work before responding, a slow response can trip the timeout and trigger a needless retry.
Retries and backoff
Delivery is at least once. A delivery that fails is retried automatically with exponential backoff — the gap between attempts grows, so a brief outage on your side recovers on its own without hammering a struggling endpoint.
Because a delivery can be retried, the same event can reach you more than once. Make your handler idempotent: dedupe on the event id (also sent as the X-Revenexx-Id header), which is stable across every redelivery of the same event.
Auto-disable
An endpoint that keeps failing is disabled so the platform stops sending to a dead URL. This is a safety valve, not a punishment — once you've fixed the endpoint, re-enable it from the customer console. Watch for it: an endpoint that silently stopped receiving events may have been auto-disabled after a sustained outage.
Ordering
Order is best-effort, not guaranteed. Retries and backoff mean a redelivered event can arrive after a later one. Don't assume order.paid always follows order.created on the wire.
When sequence matters, reconstruct it from the payload rather than from arrival order — use the time field on the envelope and the entity's own state in data. Handlers that are commutative (the end state is the same regardless of order) are the easiest to get right.
The delivery log
Every delivery attempt to an endpoint is recorded: which event, when, the response, and whether it succeeded. You can inspect this log and manually redeliver a past event — useful when your endpoint was down, you shipped a bug in your handler, or you need to replay history into a fresh system.
Where to go next
- Security — verify each delivery before you trust it.
- Webhooks overview — register an endpoint and choose topics.
- Consuming events — the App-handler alternative to webhooks.