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
}

The fields, and what separates an entry here from a webhook delivery, are on The reservation event object. Two details belong to this feed rather than to the object: id doubles as a pagination cursor, and type is drawn from the same catalog as webhook events.

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.
• created_status on a reservation.created entry is the status the booking was born in, which is not always the status it carries when you first see it. A booking promoted off the waitlist is published only once the guest accepts: its created arrives with the reservation already confirmed and created_status set to awaiting_guest. The event catalog describes that hold.
• 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. A change of company appears as company, with the company names as from / to (null when there was none). A change to contact_email, contact_phone, guest_notes or internal_notes appears only when your key reads the booking’s guest data.
• 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, and back with ending_before, exactly as for other lists — see Pagination. Internal-only bookkeeping events (raw table assignment/unassignment) are excluded from this feed entirely.