Skip to main content
​
Type de commerce, catégorie publique et établissements en brouillon

​
Nouveaux champs sur GET /api/v1/establishments/{slug}

Deux champs viennent préciser la nature de l’établissement :
  • business_type — type structurel de commerce, valeur d’une liste fermée : restaurant, wine_shop, bar, cafe, bakery, caterer, retail_store. Toujours renvoyé et jamais null. Les établissements existants ont été initialisés à restaurant.
  • public_category — libellé libre affiché publiquement (ex. « Néo bistrot & Cave à vin »), null s’il n’est pas renseigné. C’est le champ à afficher côté site.
Réponse 200 (extrait)
category est déprécié. Il reste renvoyé à l’identique — c’est désormais un simple alias de public_category — mais il sera retiré dans une prochaine version de l’API. Remplacez vos lectures de category par public_category dès maintenant ; aucune autre adaptation n’est nécessaire.
Le champ business_type étant issu d’une liste fermée, traitez toute valeur inconnue comme un cas de repli plutôt que de l’afficher telle quelle : de nouveaux types pourront être ajoutés sans changement de version.

​
Établissements en brouillon masqués

Un établissement qui n’a pas encore été activé (statut brouillon) n’est plus exposé publiquement, même si son API est activée et que la clé est valide :
  • les quatre endpoints de l’API répondent 404 Not found ;
  • les redirections /r/master_menu et /r/menus répondent 404.
Dès que l’établissement est activé, les réponses redeviennent normales. Ce comportement ne concerne que les établissements en cours de configuration ; aucune intégration en production n’est affectée.
​
Renommage du réglage de redirection des fichiers de menu
Le réglage qui autorise la redirection /r/menus s’appelle désormais menu_redirect_enabled (auparavant redirect_enabled), pour le distinguer des autres redirections.Il s’agit d’un renommage interne du réglage : l’URL, les paramètres et le comportement de l’endpoint sont inchangés. Rien à modifier côté intégration — l’option reste opt-in et activable par l’administrateur de l’établissement.
​
Lancement de l'API v1
Première version publique de la plateforme d’intégration Le Commis. Un établissement peut désormais diffuser ses informations vers des sites externes via trois canaux complémentaires.

​
API v1 (lecture seule)

Quatre endpoints JSON, tous authentifiés par le header X-Api-Key et scopés sur le slug de l’établissement :

Établissement

GET /api/v1/establishments/{slug} — identité, contact, localisation, logo.

Horaires

GET /api/v1/establishments/{slug}/hours — horaires réguliers et exceptionnels.

Liste des menus

GET /api/v1/establishments/{slug}/menus — menus web et fichiers du menu (champ assets) associés.

Détail d'un menu

GET /api/v1/establishments/{slug}/menus/{menu_type_slug} — sections et items.
  • Authentification : header X-Api-Key, clé serveur-à-serveur propre à chaque établissement. L’API doit être activée (public_api_enabled) dans les réglages de l’établissement.
  • Quota de requêtes : 120 requêtes/heure par clé et 500 requêtes/heure par IP. Un dépassement renvoie 429 Rate limit exceeded.
  • Détection de changement : chaque réponse expose un champ content_revision (entier monotone par établissement) pour invalider un cache ou déclencher un re-fetch.
Le champ content_revision est le moyen recommandé pour savoir si vous devez re-lire l’API : conservez la dernière valeur connue et ne rechargez que lorsqu’elle augmente.

​
Redirections de fichiers

Des URLs plug-and-play en 302 à coller directement dans une balise <img>, <iframe> ou un lien :
  • GET /r/master_menu?establishment={slug} — fichier de la Carte unifiée (toujours servi).
  • GET /r/menus?establishment={slug}&menu_type={menu_type_slug}&locale={fr|en} — fichier web du menu courant (nécessite redirect_enabled).

​
Webhooks sortants

Un événement disponible : establishment.content_updated. Le webhook est un signal (pas un transport de contenu) — le payload indique quelles ressources ont changé et la nouvelle content_revision, à charge pour le récepteur de re-lire l’API.
  • Signature HMAC-SHA256 via le header X-LeCommis-Signature, vérifiable à temps constant.
  • 5 tentatives avec backoff croissant ; debounce de 30 s qui fusionne les changements rapprochés.
  • HTTPS obligatoire côté récepteur.
Le webhook ne transporte jamais le contenu lui-même : à réception, vérifiez la signature puis re-lisez les endpoints concernés pour récupérer les données à jour.

​
i18n

Contenu de menu disponible en français (défaut) et anglais via le query param ?locale=fr|en sur les endpoints menus. Fallback automatique en → fr sur le contenu manquant.