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 — what holds across every operation: the call shape, the identity map, cursor paging, rollout phases, the webhook stream, how fresh each family of data is, and — stated in one place rather than discovered by failing — what this API does not cover.
• API Reference — the operations themselves, grouped by domain.
• Changelog — what became available, newest first.

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 refreshed state, never proxied per request to the platforms — so your polling cannot exhaust a platform's rate limits.

Freshness is not uniform, and you should code for that. The platform-observed half of a store's status (observed.*, and the discrepancy derived from it) comes from a sweep that runs hourly and today covers DoorDash, UberEats and GrubHub only. Storefronts on other platforms are never swept, and even on the three that are, roughly a third have no reading inside the last 24 hours. lastPolledAt is the field that tells you the truth — it is the timestamp of the reading, not of your request. Treat a stale lastPolledAt as "we do not currently know", not as "nothing has changed", and do not drive an automated decision off an observation you have not checked the age of. desired.* carries no such caveat: it is OneTablet's own intended state and is always current.

• 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.