The webhook event object

A webhook event is the JSON body Service POSTs to an endpoint you registered. The object the event is about travels inside it, which is why the envelope is the same shape for every event type.

Fields

idstring

Opaque event id. Stable across endpoints and across delivery retries, so it is the key to deduplicate on.

objectstring

Possible values: event

The object type: always event.

typestring

Possible values: reservation.created reservation.pending reservation.confirmed reservation.declined reservation.updated reservation.partially_seated reservation.seated reservation.completed reservation.cancelled reservation.no_show reservation.guarantee_requested reservation.guarantee_charged reservation.guarantee_refunded reservation.guarantee_released reservation.guarantee_payment_failed guest.created guest.updated guest.deleted guest.merged guest.unmerged feedback.received waitlist_entry.created waitlist_entry.promoted waitlist_entry.updated waitlist_entry.cancelled waitlist_entry.expired hold.created hold.converted hold.released hold.expired

The event name, e.g. reservation.created. What each one means, and which object data.object then holds, is in the webhook event catalog.

createdstring (date-time)

When the event was generated: ISO 8601 in UTC (…Z), unlike the timestamps inside data.object, which carry the restaurant’s offset.

livemodeboolean

False for events generated by the back-office “send test event” action.

api_versionstring

The API version pinned on the endpoint that received this event.

dataobject

The object the event is about, and on *.updated events what it was before.

objectobject

The public resource the event is about, in the same shape the REST API returns for it.

previous_attributesobjectoptional

Changed fields mapped to their prior value. Present only on *.updated events, and only for fields whose previous value is derivable.

Verify before you read any of it

The body is untrusted until the Service-Signature header checks out. Verify a signature has the algorithm and a tested implementation to copy.

id is stable across retries

The same change delivered twice carries the same id, which is what makes it the key to deduplicate on — Delivery semantics says why you have to. It is not the evt_… of the reservation event describing the same change: those are numbered separately.

Two clocks in one payload

created on the envelope is ISO 8601 in UTC, ending in Z — the instant the event was emitted. Every timestamp inside data.object — starts_at, created_at, updated_at — carries the restaurant’s UTC offset instead, matching the REST API. Parse each field by its own suffix rather than assuming one zone for the payload.

data.object is the full resource

Whatever the event is about arrives whole, in the same shape the REST API returns for it — a reservation, a guest, a hold, a waitlist entry. Guest data is included on every delivery, whatever scopes the key behind the endpoint holds, and a nested guest is always its gst_… id. What each type means is in the event catalog.

data.previous_attributes appears only on *.updated events, and only for fields whose previous value is derivable — its absence is not a claim that nothing changed.