Booking Events

​

Overview

​

Payload

{
  "event": "booking.updated",
  "timestamp": 1756100000000,
  "venue_id": "venue123",
  "venues_group_id": null,
  "data": {
    "id": "3f6c1b2a-9d4e-4f7a-b0c8-2e5a7d9f1c3b",
    "public_id": "nX4fQ2hB",
    "status_id": "Zx8Kp3Qm7nRt",
    "contact_id": "cli_7hJk2Pq9Rt4M",
    "events": [ { "id": "rsv_8fj2kQpL0aXc", "date": "2026-09-10", "pax": 40 } ]
  }
}

​

Delivery semantics

• One webhook per logical mutation. Changes are coalesced over a short window (~10 seconds): creating a 3-day booking, or changing the status of a multi-event booking, delivers one webhook with the final state - not one per event.
• No-op suppression. An update that leaves the payload identical to the last delivered one is not delivered.
• Upsert semantics. The first delivered event for a booking that existed before your webhook was created (or before the feature went live) may be a booking.created. Treat created and updated as upserts of the same resource.
• Booking ID changes. When a single-event booking gains a second event, its id changes (new group ID). You then receive a booking.updated carrying the new id; the event IDs (events[].id) never change, so match on the events you already hold and re-key your side.
• New webhooks warm-up. A newly created webhook can take up to 5 minutes to start receiving booking events.
• Deliveries use the standard envelope, HMAC signature and retry policy - see Webhooks introduction and Security.

​

Typical integration loop

1. Subscribe to booking.created + booking.updated + booking.deleted.
2. On each delivery, upsert the booking in your system keyed by its id, and store the events[].id list: if a later delivery arrives under a new booking id, the shared event IDs identify it as the same booking.
3. Backfill or reconcile at any time by paging through GET /bookings (optionally windowed with created_from/created_to).