> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lecommis.fr/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Historique des évolutions de l'API, des redirections de fichiers et des webhooks Le Commis.

<Update label="Juillet 2026" description="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.

  ```json Réponse 200 (extrait) theme={null}
  {
    "name": "Au Bistrot",
    "business_type": "restaurant",
    "public_category": "Restaurant français",
    "category": "Restaurant français"
  }
  ```

  <Warning>
    **`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.
  </Warning>

  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.
</Update>

<Update label="Juin 2026" description="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.
</Update>

<Update label="Juin 2026" description="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 :

  <CardGroup cols={2}>
    <Card title="Établissement" href="/api-reference/establishment/get-establishment">
      `GET /api/v1/establishments/{slug}` — identité, contact, localisation, logo.
    </Card>

    <Card title="Horaires" href="/api-reference/establishment/get-hours">
      `GET /api/v1/establishments/{slug}/hours` — horaires réguliers et exceptionnels.
    </Card>

    <Card title="Liste des menus" href="/api-reference/menus/list-menus">
      `GET /api/v1/establishments/{slug}/menus` — menus web et fichiers du menu (champ `assets`) associés.
    </Card>

    <Card title="Détail d'un menu" href="/api-reference/menus/get-menu">
      `GET /api/v1/establishments/{slug}/menus/{menu_type_slug}` — sections et items.
    </Card>
  </CardGroup>

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

  <Note>
    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.
  </Note>

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

  <Note>
    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.
  </Note>

  ## 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.
</Update>