Overview

The OneTablet Management API is the partner-facing interface for operators and the systems acting on their behalf — POS vendors, back-office platforms, data and ETL pipelines, and operations agents. It exposes the orders your restaurants receive and the places and brands those restaurants run as, normalised into one shape regardless of which delivery platform they came from.

This site is generated from the contract itself. Every operation, every field, every enum value and every description on an API Reference page is read out of the OpenAPI document that is emitted from the source of the API — so a page here cannot describe an API we do not serve.

Where to start

• Getting Started — make your first authenticated call, then learn what a failure looks like and when to retry it.
• Concepts — the four things that hold across every operation: the call shape, the identity map, cursor paging, and which rollout phase an operation belongs to.
• API Reference — the operations themselves, grouped by domain.

What this API is for

• Your own stores only. Every credential is scoped to one organization. organizationId is never a request parameter — it is derived from the credential and enforced at the data layer.
• Reads are cache-served. Reads that reflect delivery-platform state are answered from OneTablet's own continuously-refreshed state, never proxied per request to the platforms — so your polling cannot exhaust a platform's rate limits.
• Orders are read-only. Order lifecycle actions (accept, mark ready, cancel) happen in the kitchen, on the OneTablet tablet, so this API can never contradict the people actually cooking. You observe every transition; you do not drive them.
• Additive evolution. New optional fields and new operations may arrive at any time. Nothing is removed or narrowed. Write your client to ignore fields it does not recognise and it keeps working across releases.