List stores

POST/management/stores/fetchStores

The identity map: your storefronts, with the complete join between OneTablet's identifiers and the delivery platform's.

Each store carries Store.id and Store.code (ours), Store.platformStoreId (the platform's own), the owning Store.brand and Store.location each with their own ids and codes, and Store.wentLiveAt.

This is deliberately the first operation to integrate: one call gives the complete crosswalk, and everything else in the API is addressed by identifiers it returns. Ids are stable forever — build your mapping on them once, at onboarding.

Narrow the result with storeIds, locationIds, brandIds and platforms; omitting them all returns your whole estate, which you page through.

Scope: storefronts at a kitchen you own, OR selling a brand you own. Retired storefronts and OneTablet's internal in-app-test pseudo-platform are excluded, so every row is a real storefront on a real platform.

Store.platformStoreId and Store.storeUrl are STORED values refreshed by an hourly sweep — this operation makes no live call out to a delivery platform, so it is cheap to poll but can lag a change made directly on one by up to an hour.

Paging: sorted by id ascending. Loop until nextCursor is absent. An estate of several thousand storefronts is normal; page, do not ask for everything at once.

Safe to retry: this operation is read-only and idempotent.

Request

application/json

required

pagePageRequest
Cursor pagination.
storeIdsstring[]
Narrow to these Store.id values — the ids fetchStores itself returns.
locationIdsstring[]
Narrow to storefronts at these kitchens (Location.id, as returned by fetchLocations).
brandIdsstring[]
Narrow to storefronts selling these brands (Brand.id, as returned by fetchBrands).
platformsstring[]
Narrow to these platform slugs, e.g. ["doordash", "ubereats"].

Matched case- and punctuation-insensitively against the platform name, so "doordash", "DoorDash" and "Door Dash" all select the same platform. Same OPEN enum as Store.platform: a slug we do not recognise simply matches nothing rather than erroring.

{
  "page": {
    "limit": 50,
    "cursor": "<cursor>"
  },
  "storeIds": [
    "<storeIds>"
  ],
  "locationIds": [
    "<locationIds>"
  ],
  "brandIds": [
    "<brandIds>"
  ],
  "platforms": [
    "<platforms>"
  ]
}

Responses

200 — One page of your storefronts with their OneTablet and platform identifiers, and the cursor for the next page.

Headers

x-mealco-tx-idstringoptional
The correlation id for this call, echoed on every response — a 200 exactly as much as a 400, 401 or 500. Quote it when reporting a problem and we can find every log line for the request, in every service it touched. You may also send your own x-mealco-tx-id on the request and we adopt it, so your correlation id becomes ours. Not marked required for one reason: a request whose JSON body is malformed is rejected before it reaches an operation, so no id exists yet and that single response carries neither this header nor the txId field of the error body. Everything that reaches an operation carries it.

storesStore[]
The page of storefronts, sorted by id ascending.
nextCursorstring
Opaque cursor for the next page. Absent means the last page.

About Stores

The places you operate and the brands you operate there.

OneTablet models a restaurant business in three layers, and every other section of this API assumes them. A brand is a menu concept — what a customer sees on a delivery app. A location is a physical address with a kitchen in it. A store is one storefront: a single brand, at a single location, on a single platform — so a location running two brands on three platforms has six stores, each with its own menu, hours and pause state.

The directory reads join on IDS, never on display names: every store carries its location.id and brand.id, and a location carries the id of each brand it runs.

Start here — a location carries the timezone that every schedule, report window and business day elsewhere on this API is interpreted in.

Every operation is org-scoped to the organization your api key resolves to, and nothing here calls out to a delivery platform live. The directory reads (fetchLocations, fetchBrands, fetchStores, fetchStore, fetchStoreHours, fetchStoreMenus) never mutate; setLocationHours and setLocationSpecialHours write a location you own.

Whether a storefront is currently taking orders is NOT here — fetchStoreStatuses, pauseStores, unpauseStores and the store.status.changed webhook live in the Store status section. This section answers "what do I operate"; that one answers "is it open right now, and does the platform agree".