> ## Documentation Index
> Fetch the complete documentation index at: https://docs.way.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Delivery and Retries

> Timeouts, retry policy, and how to build a reliable consumer

## Delivery

* Events are delivered as `POST` requests with a JSON body of `{ "event", "payload" }` and, when a secret is set, an `X-Way-Signature` header.
* Your endpoint has **10 seconds** to respond. Any `2xx` counts as delivered; anything else - including timeouts - counts as failed.

## Retries

* Failed deliveries are retried at **10-minute intervals**, in the order they were originally triggered.
* After the **third failed retry**, no further attempts are made and the delivery stays in the failed state, visible in the dashboard webhook logs.

## Building a reliable consumer

* **Acknowledge fast, process async.** Return `200` as soon as the signature checks out; do the real work on a queue. Slow processing is the top cause of spurious retries.
* **Expect duplicates.** Retries mean the same event can arrive more than once, and deliveries carry no unique delivery ID - deduplicate on business keys such as `bookingId` plus the event type (and a timestamp field where the payload has one).
* **Don't rely on ordering.** Retries are re-queued, so a `booking.cancelled` retry can arrive after a later event was already delivered. Treat the API as the source of truth for current state.
* **Reconcile after downtime.** If your endpoint was down past the retry window, recover by polling - [Get bookings](/api-reference/bookings/get-bookings) with `updatedFrom`/`updatedTo` filters covers the booking events.