Delivery

Retries, ordering, the delivery log, and what your endpoint must return for a webhook to count as delivered.

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-2xx status, 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.

The delivery-log and manual-redelivery calls are in the API Explorer. The behavior described here — at-least-once, backoff, auto-disable, replay — is the contract; the call shapes are there.

Where to go next

Was this page helpful?