Webhook delivery reworked: per-type, ordered per user, at least once

Availability: Sandbox since November 3, 2026 · Production since November 5, 2026

Webhook delivery has been reworked so a burst of one event type no longer delays others. See Webhooks for the full delivery rules.

• At least once: an event can be sent more than once, for example after a restart. Deduplicate on the event id.
• id semantics: id is unique and increases within an event type, but not across types. Do not use it to order, say, a market order against a settlement.
• Ordering: market order, parlay, transaction and KYC status events are sent in order per user. Events for different users can be in flight at the same time. Settlements and contract, market, event and tournament updates are sent a few at a time and can arrive slightly out of order. When several updates to the same contract, market, event or tournament are waiting, only the newest is sent.
• Best effort: market_selections and matched_order events are not retried. Use the market sequenceNumber to discard a market_selections update that arrives out of order.
• Responses: reply with a 2xx to acknowledge. A 5xx or a timeout is retried with backoff, and if it continues, delivery to your endpoint is paused until /health answers. A 429 is retried after its Retry-After header. A 404 is treated as accepted. Any other 4xx means the event was rejected: it is not retried and delivery moves on. An event that keeps failing while others of its type are accepted is eventually given up on, so one event your endpoint cannot handle does not hold back the rest.
• Registration: a newly registered endpoint receives events from after it registered, not earlier history. Unregistering and registering again also starts fresh.

If you relied on id giving a global order across event types, switch to per-user ordering and per-type id comparison.