Restaurant API
An HTTP/JSON API for the restaurant team's own code — your backend, your BI, your internal app, your low-code flows. Same auth, same per-solution permissions, same audit log.
Run Sinqro from your own backend.
Push orders into your loyalty engine when they land in Sinqro. Sync catalog changes from your internal admin tool back into every channel. Stream live operations into the data warehouse the chain already runs reports against. Trigger automations from the central ops backend when an internal alert fires. Everything your team already does inside Dashboard is reachable as HTTP/JSON — with the same auth model, the same per-solution permissions, and the same audit log.
Restaurant API is NOT…
If you are a POS vendor, a marketplace or a delivery company looking to plug your system INTO Sinqro — that is the Integration API and it lives under /store. If you are building a software product on top of Sinqro to sell it to OTHER restaurants — that is the developer story and the right doorway is /collaborate/developers (MCP + REST + OpenAI function-calling, with billing and tenancy considerations). Restaurant API is exclusively for the team operating the restaurant: same hands, just writing code instead of clicking through Dashboard.
→ Integrations (for vendors) → Developers (for SaaS-on-Sinqro)
What Restaurant API does for every solution you have active.
Concrete actions per combo — not abstract capabilities. If a venue has the solution active, this is what Restaurant API actually lets the team do.
GET pending orders, POST acceptance, subscribe to webhook fires when a new order lands — straight into your in-house backend, your loyalty engine, or a Make/Zapier flow. Same per-solution permissions, same audit log your team already has in Dashboard. Not for vendors integrating a POS — that is the Integration API at /store.
Open solution page →Run a nightly cron from the restaurant's own infra that pushes the new Saturday menu, flags out-of-stock items, regenerates allergen flags after a supplier change. Same Master Catalog primitives Menu Studio writes against, but driven by the restaurant team's code instead of a UI.
Open solution page →Plug the same Live Data feed Dashboard renders into the restaurant's in-house TV in the office, a custom Power BI report, or a Grafana board. Polling, webhooks or server-sent events — pick what fits your stack. Not for building a Live Data resale product; that's the developer story.
Open solution page →Hit the same ticket and settlement feed Data Sync ships to Holded or A3, but fan it out into the restaurant's own Snowflake, BigQuery or a custom Postgres. Useful when the chain's BI team wants the raw stream instead of a pre-built integration.
Open solution page →From the chain's central ops backend, create or toggle Sinqro automations programmatically — "pause Glovo on every venue when our internal SLA monitor flags red", "raise floor prices on Friday at 19:00". Same rule engine Dashboard surfaces, controlled from the restaurant team's code.
Open solution page →Query the same forecasts, menu-engineering signals and pricing flags Dashboard renders, but into the restaurant's existing BI — Looker, Metabase, Power BI, an internal Streamlit. No screenshot exports, no manual copy-paste from the Analytics screen.
Open solution page →