Réservations

Une réservation, c’est une table réservée pour un service et une date de service donnés. C’est là qu’aboutit le reste de cette API : une lecture de disponibilité dit ce qui est réservable, une option retire un créneau de la vente et les deux finissent en réservation.

La lecture demande la portée reservations:read. Créer, modifier et annuler demandent reservations:write. La forme de l’objet, ses statuts et les champs que votre clé peut voir sont sur L’objet réservation.

Points de terminaison

Point de terminaison	Ce qu’il fait
POST /v1/reservations	Réserve une table selon les règles du restaurant. Idempotency-Key est obligatoire et un 201 ne veut pas dire confirmé — lisez status.
GET /v1/reservations	Liste les réservations du restaurant, paginées par curseur, filtrables par date de service, statut, origine et updated_since.
GET /v1/reservations/{id}	Récupère une réservation par son identifiant resv_….
PATCH /v1/reservations/{id}	Déplace le jour, l’heure, le nombre de couverts ou la section, et revérifie la réservation face aux règles.
POST /v1/reservations/{id}/cancel	Annule la réservation et rend la table. Une annulation est un état, pas une suppression.
GET /v1/reservations/{id}/events	L’historique de la réservation, du plus ancien au plus récent.

Le flux d’événements

GET /v1/reservations/{id}/events est le seul point de terminaison ici qui ne renvoie pas une réservation. Chaque entrée décrit un changement et non l’état courant de la réservation ; la forme est sur L’objet événement de réservation et le contenu de chaque data est dans Événements de réservation.

Voir aussi

• Options — prenez le créneau avant de prendre la réservation.
• Disponibilité — ce qui est réservable avant d’essayer.
• Webhooks — la même réservation, poussée vers vous.