L'objet événement de réservation

Un événement de réservation, c’est une entrée de l’historique immuable d’une réservation. Il revient de GET /v1/reservations/{id}/events et de ?expand=events sur une lecture.

Champs

Le tableau ci-dessous est généré depuis la spécification OpenAPI et reste en anglais, comme la référence de l'API : noms de champs, valeurs d'énumération et descriptions viennent du backend. Une traduction serait une copie qui ment dès la première évolution du contrat.

objectstring

Valeurs possibles : reservation_event

The object type: always reservation_event.

idstring

The event’s id, evt_…. Opaque and permanent. Not the id of the webhook event that announced the same change: the two are numbered separately.

typestring

Valeurs possibles : reservation.created reservation.confirmed reservation.declined reservation.updated reservation.pending reservation.partially_seated reservation.seated reservation.completed reservation.cancelled reservation.no_show

What happened, named like the webhook event for the same change.

• reservation.created: the booking was made.
• reservation.pending: it became a request awaiting the restaurant’s decision.
• reservation.confirmed: the restaurant accepted it.
• reservation.declined: the restaurant turned the request down.
• reservation.updated: its details or its tables changed.
• reservation.partially_seated: part of the party was seated.
• reservation.seated: the party was seated.
• reservation.completed: the party left.
• reservation.cancelled: it was cancelled — data.cancellation_reason says how.
• reservation.no_show: the party did not come.

created_atstring (date-time)

When it happened: ISO 8601 with the restaurant’s UTC offset.

dataobject

What changed, keyed per event type — statuses as from_status/to_status, field edits under changes. Internal ids, staff identity and the staff’s own notes are stripped. Treat the key set as open.

Six keys carry the guest’s own data and appear only when your key could read that field on the booking — that is, when it carries guests:read:

• contact_email, contact_phone, guest_notes — the booking’s own contact details and the note the guest left, inside changes when one of them is edited.
• submitted_guest_name, submitted_email, submitted_phone — on the reservation.created event, what the booker actually typed, recorded when it differs from the guest profile the booking was matched to.

On reservation.cancelled, cancellation_reason says who ended the booking and how:

• partner_api is a cancel YOU made through POST /v1/reservations/{id}/cancel.
• guest_self_service is the guest cancelling from their own manage link.
• guarantee_expired is a card request that lapsed unpaid.

Anything else was typed by the restaurant; match on the three named values and pass the rest through.

Il décrit un changement, pas un état

Une entrée dit ce qui s’est passé à ce moment-là. Pour savoir ce qu’est la réservation maintenant, récupérez la réservation. C’est la différence avec un webhook, dont le data.object est la réservation entière.

L’evt_… d’ici n’est pas l’id du webhook qui a annoncé le même changement. Les deux sont numérotés séparément : dédupliquez les livraisons de webhook sur l’identifiant du webhook.

Ce que porte data

L’ensemble des clés dépend du type d’événement et reste ouvert — lisez celles que vous connaissez et ignorez le reste. Les identifiants internes, l’identité du personnel et ses notes propres sont retirés, ce qui explique qu’une mise à jour qui n’a fait que réattribuer des tables donne un diff vide. Événements de réservation parcourt les formes type par type.

Six clés portent les données du client et n’apparaissent que si votre clé pouvait lire ce champ sur la réservation. Le champ ci-dessus les nomme.