Support et exhaustivité des données

La réserve sur l'exhaustivité, dite simplement

L'API Partenaire expose les enregistrements saisis après l'activation de la fonctionnalité pour ce restaurant — les livraisons comme les collections. Elle ne prétend pas détenir l'historique complet d'un restaurant, et elle n'en reconstituera pas un.

Cela compte davantage qu'il n'y paraît :

• Un résultat vide n'est pas la preuve que rien ne s'est passé. Cela peut vouloir dire que le restaurant n'était pas encore activé, ou qu'un appareil n'a pas encore téléversé.
• Un décompte issu de cette API n'est pas un chiffre de conformité. N'en imprimez pas un sur un rapport qui se lit comme un audit.
• Si vous avez besoin de connaître la date d'activation d'un restaurant, demandez-nous ou demandez au client. Elle n'est pas exposée par l'API aujourd'hui — si vous en avez besoin comme champ, dites-le-nous et elle en deviendra un.

Les collections le disent dans leur propre réponse : stateKind vaut received-shadow-snapshot, c'est-à-dire l'état que cette API a reçu, pas l'état que détient l'application du restaurant. Les deux concordent dans le cas ordinaire et divergent exactement quand un appareil n'a pas encore téléversé.

Une fois un restaurant activé, les enregistrements arrivent de façon fiable, y compris ceux saisis pendant qu'un appareil était hors ligne : ceux-là sont téléversés à la reconnexion, et c'est pourquoi l'interrogation incrémentale doit se chevaucher et pourquoi capturedAt et receivedAt figurent tous les deux sur chaque enregistrement.

Versionnage

Tous les chemins sont préfixés par /v1. À l'intérieur de cette version, nous pourrons :

• ajouter des champs à une réponse, et
• ajouter des endpoints et des paramètres optionnels.

Les deux sont rétrocompatibles, et aucun ne sera annoncé comme un changement cassant — analysez donc avec souplesse : ignorez les champs que vous ne connaissez pas plutôt que d'échouer dessus.

Nous ne supprimerons pas un champ, nous n'en changerons pas le type, nous ne changerons pas le sens d'un champ existant et nous ne rendrons pas obligatoire un paramètre optionnel, à l'intérieur de /v1. Tout ce qui l'exigerait arriverait sous /v2, à côté de /v1, avec un préavis.

Le document OpenAPI est généré à partir du service en fonctionnement : c'est donc la description faisant autorité de ce qui est déployé en ce moment. Si cette documentation et ce document divergent, c'est le document qui a raison et nous avons une page à corriger — dites-le-nous.

Contrôles de santé

Deux endpoints publics, sans authentification :

/health/ready est celui à interroger si vous nous supervisez. Les sondes réussies ne sont pas consignées au journal d'audit, une supervision n'ajoute donc pas de bruit.

Obtenir de l'aide

Écrivez à contact@backresto.com. Ce qui rend une réponse rapide :

• le requestId du document problème, ou le X-Request-ID que vous avez envoyé ;
• le préfixe public de votre clé — la moitié brp_… avant le point, jamais le secret ;
• l'environnement, l'endpoint, et à peu près quand.

Ne nous envoyez jamais le secret d'une clé — le préfixe public l'identifie sans ambiguïté. Si un secret est parti là où il n'aurait pas dû, dites-le dans l'objet du message et envoyez le préfixe : la révocation est immédiate, et c'est tout le remède. Voyez Obtenir une clé pour le reste du cycle de vie d'une clé.

Demander plus

Ce qui existe ici existe parce que quelqu'un l'a demandé. Les températures de cuisson et de refroidissement, les plans de nettoyage, les étiquettes et un endpoint MCP hébergé étaient tous sur cette liste il y a quelques mois ; ce sont aujourd'hui des collections et un endpoint.

Ce qui y figure encore : des webhooks plutôt que de l'interrogation, un curseur incrémental sur les collections, une date d'activation sur le restaurant, et une connexion OAuth pour les clients MCP qui refusent une clé. Celle qui vient ensuite est décidée par ceux qui demandent. Alors demandez.