Skip to main content

​
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 with updatedFrom/updatedTo filters covers the booking events.