Skip to main content
Chaque mise en production qui touche l’API partenaire ou les webhooks a son entrée ici. Les entrées marquées Changement cassant demandent une action de votre part ; les autres non. Abonnez-vous au flux RSS (bouton ci-dessus) pour être prévenu des nouvelles entrées.
​
Webhooks
Webhooks

​
Événements clients et format d’événement v1

Rétrocompatible, aucune action requise : les endpoints existants conservent leur format actuel jusqu’à leur migration.Ajouts
  • Format d’événement v1 : id, type, api_version, created, restaurant_id et data.object, qui reprend la représentation de la réservation ou du client dans l’API partenaire.
  • data.previous_attributes sur les événements *.updated.
  • En-tête de signature EatNow-Signature (t=…,v1=…) ; secrets préfixés whsec_.
  • Événements customer.created, customer.updated, customer.deleted et customer.merged (format v1 uniquement).
  • Endpoints /webhook-endpoints (scope WEBHOOKS_WRITE) : création, lecture, liste, modification, suppression, rotate-secret et test. Un endpoint ne reçoit que les événements que sa clé API peut lire.
Modifications
  • Les endpoints créés depuis le tableau de bord utilisent le format v1. Un endpoint existant peut migrer depuis Paramètres › Intégrations › Webhooks ; la migration est définitive.
Référence des webhooks · Guide de migration
​
API partenaire
API partenaire

​
Ressource clients

Rétrocompatible, aucune action requise.Ajouts
  • Scopes CUSTOMERS_READ et CUSTOMERS_WRITE (CUSTOMERS_WRITE nécessite aussi CUSTOMERS_READ).
  • GET /customers : pagination par curseur, paramètre updated_since, et filtres email, phone, external_id et tag.
  • GET /customers/{id}.
  • POST /customers : rapprochement d’un client existant par external_id, puis téléphone, puis email ; on_match définit le comportement en cas de correspondance (return_existing, update, create_new).
  • PATCH /customers/{id}.
  • GET /customer-fields : champs personnalisés du restaurant.
  • POST /reservations : customer.id pour lier un client existant, et customer.on_match.
  • GET /reservations : filtre customer_id.
Référence des clients
​
Webhooks
Webhooks

​
Livraison et nouveaux essais des webhooks

Rétrocompatible : format, signature et noms d’événements inchangés.Ajouts
  • En-têtes X-EatNow-Attempt, X-EatNow-Delivery-Log-Id, et X-EatNow-Test: true sur les livraisons de test.
  • Historique des livraisons des 30 derniers jours, avec renvoi, dans Paramètres › Intégrations › Webhooks.
Modifications
  • RESERVATION_UPDATED est désormais publié pour les modifications faites depuis la caisse (NowOS, Lightspeed), par l’API partenaire, par une annulation du staff et par les changements de statut automatiques (terminée, no-show).
  • Les livraisons sont réessayées pendant 3 à 5 heures après une réponse 5xx, 408 ou 429, une erreur réseau ou un délai dépassé. X-EatNow-Delivery est identique d’un essai à l’autre ; X-EatNow-Timestamp est l’heure de l’événement.
  • Toute autre réponse 4xx est définitive et n’est pas réessayée.
  • Le préfixe d’en-tête X-EatNow-* est réservé : les en-têtes personnalisés qui l’utilisent ne sont plus envoyés.
Référence de l’ancien format des webhooks