É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
}

Champ	Description
object	Toujours "reservation_event".
id	Identifiant d’événement opaque (evt_…). Utilisable comme curseur de pagination.
type	Le nom de l’événement de cycle de vie, issu du même catalogue que les webhooks (reservation.created, reservation.confirmed, …).
created_at	Le moment où l’événement s’est produit (ISO-8601 avec le décalage UTC du restaurant).
data	Une petite charge utile propre à l’événement décrivant ce qui a changé — voir ci-dessous.

Ceci est un flux d’historique, pas un instantané

Contrairement à un webhook — dont le data.object est la réservation complète — une entrée ici décrit uniquement ce qui a changé lors de cet unique événement. Pour obtenir l’état actuel de la réservation, récupérez la réservation elle-même (en anglais). Les identifiants internes et les identités du personnel sont retirés de data, donc vous ne verrez jamais d’identifiants de table ni qui a effectué une action.

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.
• 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.
• 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 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.