Événements de réservation

Chaque réservation conserve un historique d’événements immuable et en ajout seul — créée, confirmée, installée, mise à jour, annulée, et ainsi de suite. Lisez-le avec :

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

La réponse est une liste paginée par curseur en ordre chronologique (l’événement le plus ancien d’abord) :

{
  "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
}

Les champs, et ce qui distingue une entrée d’ici d’une livraison de webhook, sont sur L’objet événement de réservation. Deux détails appartiennent à ce flux plutôt qu’à l’objet : id sert aussi de curseur de pagination et type est tiré du même catalogue que les événements de webhook.

Le champ data, par type d’événement

La forme de data dépend du type de l’événement :

type	Forme de data	Exemple
reservation.created	L’origine de la réservation et la taille du groupe.	{ "source": "widget", "party_size": 4 }
reservation.confirmed, reservation.declined, reservation.pending, reservation.partially_seated, reservation.seated, reservation.completed, reservation.cancelled, reservation.no_show	Une transition de statut : le statut avant et après.	{ "from_status": "pending", "to_status": "confirmed" }
reservation.updated	Un diff au niveau des champs : chaque champ modifié associé à ses valeurs from / to.	{ "changes": { "party_size": { "from": 2, "to": 4 } } }

Remarques :

• reservation.created inclut toujours source et party_size ; certains parcours de réservation (par ex. les arrivées sans réservation) incluent quelques clés de contexte supplémentaires. Traitez data comme un objet ouvert et lisez les clés qui vous intéressent.
• created_status sur une entrée reservation.created est le statut dans lequel la réservation est née, qui n’est pas toujours celui qu’elle porte lorsque vous la voyez pour la première fois. Une réservation promue depuis la liste d’attente n’est publiée qu’une fois que le client a accepté : son created arrive avec la réservation déjà confirmed et created_status à awaiting_guest. Le catalogue des événements décrit cette réservation retenue.
• reservation.updated correspond à une modification de client/réservation. La table changes ne contient jamais que des champs pertinents pour l’intégrateur — les changements de valeurs d’identifiant (affectations de table ou de section) sont retirés, de sorte qu’une mise à jour qui n’a fait que réaffecter des tables produit un diff vide. Un changement d’entreprise apparaît sous company, avec les noms des entreprises en from / to (null s’il n’y en avait pas). Un changement de contact_email, contact_phone, guest_notes ou internal_notes n’apparaît que si votre clé lit les données client de la réservation.
• Des type et des clés data inconnus ou futurs peuvent apparaître. Ignorez ce que vous ne reconnaissez pas plutôt que d’échouer.

Ordre et filtrage

Les événements sont renvoyés du plus ancien au plus récent (created_at croissant, avec l’identifiant d’événement comme départage). Paginez vers l’avant avec starting_after, et vers l’arrière avec ending_before, exactement comme pour les autres listes — voir Pagination. Les événements de comptabilité interne (affectation/désaffectation brute de tables) sont entièrement exclus de ce flux.