Opera Sinqro desde tu propio backend.
Empuja los pedidos a tu motor de fidelización cuando entran en Sinqro. Sincroniza cambios de carta desde tu herramienta interna de administración hacia todos los canales. Lleva la operación en vivo al data warehouse contra el que la cadena ya saca informes. Dispara automatizaciones desde el backend central de operaciones cuando salta una alerta interna. Todo lo que tu equipo ya hace en Dashboard es accesible vía HTTP/JSON — con el mismo modelo de auth, los mismos permisos por solución y el mismo log de auditoría.
Restaurant API NO es…
Si eres vendor de POS, un marketplace o una empresa de reparto y quieres enchufar TU sistema a Sinqro, esa es la Integration API y vive en /store. Si estás construyendo un producto software sobre Sinqro para vendérselo a OTROS restaurantes, esa es la historia de developer y la puerta correcta es /collaborate/developers (MCP + REST + OpenAI function-calling, con sus consideraciones de facturación y tenancy). Restaurant API es exclusivamente para el equipo que opera el restaurante: las mismas manos, escribiendo código en lugar de clicar Dashboard.
→ Integraciones (para vendors) → Developers (para SaaS sobre Sinqro)
Qué hace Restaurant API con cada solución que tengas activa.
Acciones concretas por combinación — no capacidades abstractas. Si el local tiene la solución activa, esto es lo que Restaurant API le permite hacer al equipo de verdad.
Pide pedidos pendientes con GET, acepta con POST, suscríbete a webhooks cuando entre un pedido nuevo — directamente a tu backend interno, a tu motor de fidelización o a un flujo de Make/Zapier. Mismos permisos por solución y mismo log de auditoría que ya tiene tu equipo en Dashboard. No es para vendors integrando un POS — eso es la Integration API en /store.
Abrir página de la solución →Lanza un cron nocturno desde la propia infra del restaurante que empuje la nueva carta del sábado, marque productos agotados, regenere etiquetas de alérgenos tras un cambio de proveedor. Las mismas primitivas de Master Catalog contra las que escribe Menu Studio, pero disparadas desde el código del equipo del restaurante en vez de desde una UI.
Abrir página de la solución →Enchufa el mismo feed de Live Data que renderiza Dashboard a la TV interna de la oficina del restaurante, a un Power BI custom o a un panel Grafana. Polling, webhooks o server-sent events — elige lo que encaje con tu stack. No es para construir un producto Live Data reventa; eso es la historia de developer.
Abrir página de la solución →Tira contra el mismo feed de tickets y liquidaciones que Data Sync envía a Holded o A3, pero abanícalo al Snowflake propio del restaurante, BigQuery o un Postgres custom. Útil cuando el equipo de BI de la cadena quiere el flujo crudo en vez de una integración pre-construida.
Abrir página de la solución →pausa Glovo en todos los locales cuando nuestro monitor interno de SLA marque rojo
Abrir página de la solución →Consulta los mismos forecasts, señales de menu engineering y flags de pricing que renderiza Dashboard, pero hacia el BI existente del restaurante — Looker, Metabase, Power BI, un Streamlit interno. Sin exportar capturas, sin copia-pega manual desde la pantalla de Analytics.
Abrir página de la solución →