Connect Your Restaurant's Website to OrderRestro: Real Orders, No Re-Typing
Most restaurant websites treat online ordering as a separate system — a third-party widget bolted onto the site, feeding a tablet that sits next to the till printing out slips someone has to key into the real POS by hand. OrderRestro doesn’t need that extra step, because your website can talk to OrderRestro directly.
The Integration API: your website, calling OrderRestro like any other backend
OrderRestro exposes a REST API — /api/v1/integrations/* — built specifically for this. Your website’s own backend calls it to read the live menu, place a takeaway or delivery order, or book a table, using a scoped key created from Settings > API Keys > Integration API keys. “Scoped” means exactly that: when you create the key you tick the specific permissions it needs — say, menu:read and orders:write — and optionally lock it to a single location. A key that leaks can only ever do what it was explicitly allowed to, nothing more.
The moment an order or booking comes in through that API, it lands on the OrderRestro dashboard and the kitchen display exactly like one taken at the counter — same ticket format, same station routing, same live timer. There’s no second inbox to check and nothing to copy across by hand, because as far as the kitchen is concerned, it is an order taken at the counter; it just arrived from a browser instead of a till.
An MCP server, for when the request comes from an AI instead of a browser
Alongside the Integration API, OrderRestro ships its own MCP server at /api/v1/mcp. Point Claude Desktop, or any other MCP-compatible client, at it with a personal API key from the same Settings page, and you can ask it things like “what does today look like?” or “book a table for four at 8” in plain language. The tool set is deliberately small and non-destructive — dashboard summary, open orders, creating an order, managing reservations — and every call re-checks the exact permission the equivalent screen in the app would require. An AI assistant using your key can never do more than you personally could through the UI.
Two different jobs, two different keys
It’s worth keeping the two straight: an Integration API key has no identity of its own — it’s issued for a system, not a person, and carries whatever permission list you gave it when you created it. A personal API key (MCP) acts as you, with your own role’s exact permissions, because the AI is standing in for you specifically, not for the website. Use the first for “my website needs to place orders,” and the second for “I want to ask an AI about my restaurant.”
What this doesn’t change
Both API surfaces sit in front of the same self-hosted system described everywhere else on this site — your restaurant’s order and customer data still lives on your own server, not a third party’s cloud. Turning on website ordering or an AI integration is opt-in: nothing calls out anywhere until you create a key for it.
Full endpoint list, request/response payloads, and the complete MCP tool reference are on the API Keys & Integrations page.