Events

The events endpoint is a chronological change feed for incremental sync. Each event names what happened, when, and which order to re-fetch. It captures item-level transitions (check-in, no-show) that an order's updated_at does not reflect, so it's the reliable way to keep a copy of the data current.

See the Syncing guide for the recommended polling loop.

Requires the events:read permission.

List events

GET /admin/v0/events?since=2026-07-01T00:00:00Z
Authorization: Bearer YOUR_API_KEY

Events are returned oldest first (by occurred_at), in the paginated envelope, covering the booking domain: orders, stays, bookings, and tickets.

Query parameters

Parameter	Type	Description
`since`	string	ISO 8601 timestamp; events at or after this time
`until`	string	ISO 8601 timestamp; events at or before this time
`page`	integer	Page index (default `1`)
`per_page`	integer	Items per page (default `50`, max `200`)

Response

{
  "data": [
    {
      "id": "b1f2…",
      "action": "appointment.no_show",
      "occurred_at": "2026-07-04T10:05:00+02:00",
      "resource_type": "appointment",
      "resource_id": "0ab6af2e-…",
      "order_id": "7eeecefd-…"
    }
  ],
  "meta": { "page": 1, "per_page": 50, "total": 1, "total_pages": 1 }
}

Fields

Field	Type	Notes
`id`	string	Event id. De-duplicate by this; use it alongside `occurred_at` as your cursor reference.
`action`	string	What happened, as `<resource>.<verb>` (e.g. `appointment.no_show`). Advisory — see below.
`occurred_at`	string	When the change happened
`resource_type`	string	`order`, `stay`, `appointment`, or `ticket`
`resource_id`	string	Public id of the changed resource
`order_id`	string	Public id of the order to re-fetch (resolved even for item events)

The stable contract is `order_id` + `occurred_at`

Drive your sync off these two: an event means "order order_id changed as of occurred_at — re-fetch it." action and resource_type are useful for logging and routing, but treat them as advisory, not a fixed enum:

The action set grows over time. Handle unknown actions by re-fetching the order rather than failing.
action is prefixed by the record the event was logged on, which is sometimes the order, even for item-level changes. So a ticket cancellation may surface as order.ticket_cancelled (with resource_type: "order"), and a refund as order.refund_created — not as ticket.*. Some transitions emit more than one event. Re-fetching the order absorbs all of this correctly.

A representative (non-exhaustive) sample: order.created, order.updated, order.order_placed, order.order_edited, order.refund_created, order.stay_cancelled, order.ticket_cancelled, appointment.checked_in, appointment.no_show, appointment.cancelled, stay.checked_in, stay.dates_changed, stay.room_changed, ticket.cancelled. appointment.checked_out is no longer emitted, but older events keep it.

Changes on 4 November 2026

Bookings used to be called appointments. On 4 November 2026 booking events change name: resource_type becomes booking instead of appointment, and appointment.* actions become booking.* (booking.checked_in, booking.no_show, …). Events recorded before that date are renamed too, so re-reading the feed returns the new names. Handle both names before then, so your integration keeps working when they change.