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

# Booking Events

> booking.created, booking.updated, booking.deleted - real-time notifications for bookings (dossiers)

## Overview

Booking webhooks notify your application when a booking (dossier) is created, modified or deleted - including status changes, date/time changes, guest count changes, contact reassignment and custom field edits.

| Event                             | Triggered when                                                                        |
| --------------------------------- | ------------------------------------------------------------------------------------- |
| `booking.created` <sup>Beta</sup> | A booking is created (via the app or `POST /events/create`)                           |
| `booking.updated` <sup>Beta</sup> | Any relevant field of the booking or one of its events changes - including the status |
| `booking.deleted` <sup>Beta</sup> | The booking is deleted (all of its events)                                            |

<Note>
  Booking events are currently in **beta**: the payload structure may still evolve before general availability.
</Note>

## Payload

The `data` field carries the **full booking payload**, identical to [`GET /bookings/{id}`](/api-reference/bookings) - nested `events[]`, financial references and custom fields included.

```json theme={null}
{
  "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 } ]
  }
}
```

There is no dedicated `status_changed` event: a status change is a `booking.updated` like any other - read `status_id` (and resolve its `type`/`is_canceled` via `GET /status`) to drive your pipeline.

## 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](/api-reference/webhooks/introduction) and [Security](/api-reference/webhooks/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`).