Restaurant API
Une API HTTP/JSON pour le code de votre propre équipe de restaurant — votre backend, votre BI, votre application interne, vos flux low-code. Même auth, mêmes permissions par solution, même journal d'audit.
Exécutez Sinqro depuis votre propre backend.
Poussez les commandes vers votre moteur de fidélisation lorsqu'elles arrivent dans Sinqro. Synchronisez les changements de catalogue depuis votre outil interne d'administration vers tous les canaux. Transmettez les opérations en direct vers le data warehouse contre lequel la chaîne génère déjà des rapports. Déclenchez des automatisations depuis le backend central des opérations lorsqu'une alerte interne se déclenche. Tout ce que votre équipe fait déjà dans Dashboard est accessible via HTTP/JSON — avec le même modèle d'authentification, les mêmes permissions par solution et le même journal d'audit.
L'API Restaurant n'est PAS…
Si vous êtes un fournisseur de POS, un marketplace ou une entreprise de livraison cherchant à connecter votre système à Sinqro — c'est l'Integration API et elle se trouve sous /store. Si vous construisez un produit logiciel sur Sinqro pour le vendre à D'AUTRES restaurants — c'est l'histoire des développeurs et la bonne porte est /collaborate/developers (MCP + REST + OpenAI function-calling, avec des considérations de facturation et de tenancy). L'API Restaurant est exclusivement destinée à l'équipe qui opère le restaurant : mêmes mains, juste écrire du code au lieu de cliquer sur le Dashboard.
→ Intégrations (pour les vendors) → Développeurs (pour SaaS sur Sinqro)
Ce que Restaurant API fait pour chaque solution que vous avez active.
Actions concrètes par combinaison — pas de capacités abstraites. Si un établissement a la solution active, voici ce que Restaurant API permet réellement à l'équipe de faire.
GET des commandes en attente, POST d'acceptation, abonnez-vous aux déclencheurs de webhook lorsqu'une nouvelle commande arrive — directement dans votre backend interne, votre moteur de fidélisation ou un flux Make/Zapier. Même permissions par solution, même journal d'audit que votre équipe a déjà dans le Dashboard. Ce n'est pas pour les fournisseurs intégrant un POS — c'est l'API d'Intégration à /store.
Ouvrir la page de la solution →Lancez un cron nocturne depuis l'infrastructure propre du restaurant qui pousse le nouveau menu du samedi, marque les produits en rupture de stock, régénère les indicateurs d'allergènes après un changement de fournisseur. Les mêmes primitives de Master Catalog contre lesquelles Menu Studio écrit, mais déclenchées par le code de l'équipe du restaurant au lieu d'une interface utilisateur.
Ouvrir la page de la solution →Branchez le même flux de données en direct que le Dashboard rend dans la télévision interne du restaurant, un rapport Power BI personnalisé ou un tableau Grafana. Polling, webhooks ou événements envoyés par le serveur — choisissez ce qui convient à votre stack. Ce n'est pas pour construire un produit de revente de données en direct ; c'est l'histoire des développeurs.
Ouvrir la page de la solution →Frappez le même flux de tickets et de liquidations que Data Sync envoie à Holded ou A3, mais diffusez-le dans le Snowflake propre du restaurant, BigQuery ou un Postgres personnalisé. Utile lorsque l'équipe BI de la chaîne souhaite le flux brut plutôt qu'une intégration pré-construite.
Ouvrir la page de la solution →pause Glovo dans tous les établissements lorsque notre moniteur interne de SLA indique rouge
Ouvrir la page de la solution →Interrogez les mêmes prévisions, signaux d'ingénierie de menu et indicateurs de prix que rend le Dashboard, mais vers le BI existant du restaurant — Looker, Metabase, Power BI, un Streamlit interne. Pas d'exportations de captures d'écran, pas de copier-coller manuel depuis l'écran d'Analytics.
Ouvrir la page de la solution →