Reservation events

Every reservation keeps an immutable, append-only event history — created, confirmed, seated, updated, cancelled, and so on. Read it with:

curl "https://api.useservice.app/v1/reservations/resv_8xKQ2m4Vd0pErJ7sN1aZ9bQ/events" \
  -H "Authorization: Bearer $SERVICE_API_KEY"

The response is a cursor-paginated list in chronological order (oldest event first):

{
  "object": "list",
  "data": [
    {
      "object": "reservation_event",
      "id": "evt_3Td9Lp0WqZ",
      "type": "reservation.created",
      "created_at": "2026-06-20T11:04:18+02:00",
      "data": { "source": "widget", "party_size": 4 }
    },
    {
      "object": "reservation_event",
      "id": "evt_5P2bU6q8Zh",
      "type": "reservation.confirmed",
      "created_at": "2026-06-20T11:30:00+02:00",
      "data": { "from_status": "pending", "to_status": "confirmed" }
    }
  ],
  "has_more": false
}

Field	Description
object	Always "reservation_event".
id	Opaque event id (evt_…). Usable as a pagination cursor.
type	The lifecycle event name, from the same catalog as webhooks (reservation.created, reservation.confirmed, …).
created_at	When the event occurred (ISO-8601 with the restaurant’s UTC offset).
data	A small, event-specific payload describing what changed — see below.

This is a history feed, not a snapshot

Unlike a webhook — whose data.object is the full reservation — an entry here describes only what changed in that one event. To get the reservation’s current state, fetch the reservation itself. Internal ids and staff identities are stripped from data, so you will never see table ids or who performed an action.

The data field, by event type

The shape of data depends on the event type:

type	data shape	Example
reservation.created	The booking origin and party size.	{ "source": "widget", "party_size": 4 }
reservation.confirmed, reservation.declined, reservation.pending, reservation.partially_seated, reservation.seated, reservation.completed, reservation.cancelled, reservation.no_show	A status transition: the status before and after.	{ "from_status": "pending", "to_status": "confirmed" }
reservation.updated	A field-level diff: each changed field mapped to its from / to values.	{ "changes": { "party_size": { "from": 2, "to": 4 } } }

Notes:

• reservation.created always includes source and party_size; some booking paths (e.g. walk-ins) include a few extra context keys. Treat data as an open object and read the keys you care about.
• reservation.updated corresponds to a guest/booking edit. The changes map only ever contains integrator-meaningful fields — id-valued changes (table or section assignments) are stripped, so an update that only reassigned tables yields an empty diff.
• Unknown / future types and data keys may appear. Ignore what you do not recognise rather than failing.

Ordering and filtering

Events are returned oldest-first (created_at ascending, with the event id as a tie-breaker). Page forward with starting_after exactly as for other lists — see Pagination. Internal-only bookkeeping events (raw table assignment/unassignment) are excluded from this feed entirely.