List store statuses
Status for any set of stores — one storefront or the whole estate — in one operation.
Each status carries three things, distinctly: desired (what OneTablet is configured to do), observed (what the platform reports), and discrepancy (present always; its classification fields populate only when the two disagree).
Served from OneTablet's stored state, never proxied per request, so this never touches platform rate limits.
FRESHNESS IS NOT UNIFORM — lastPolledAt is the field that tells you the truth. observed (and the discrepancy derived from it) comes from a sweep that runs HOURLY and covers DoorDash, UberEats and GrubHub ONLY; storefronts on other platforms are never swept, and even on those three roughly a third carry no reading inside 24 hours. A store that has never been polled is absent from this feed entirely rather than returned with an unknown state. Treat a stale lastPolledAt as "we do not currently know", NOT as "nothing has changed", and check its age before driving an automated decision off observed. desired carries no such caveat — it is OneTablet's own intended state and is always current.
Pass storeIds for specific stores, filter by locationIds / brandIds / platforms, or filter hasDiscrepancy: true for just the stores needing attention. Omitting a filter means no filter, exactly as on fetchStores.
Paging: sorted by storeId ascending. Loop until nextCursor is absent.
Safe to retry: this operation is read-only and idempotent.
Request
- storeIdsstring[]
Narrow to specific storefronts.
- locationIdsstring[]
Narrow to storefronts at these kitchens.
- brandIdsstring[]
Narrow to storefronts selling these brands.
- platformsstring[]
Narrow to these platform slugs.
- statestring
Filter on the desired state.
closedSpecialHoursis accepted but never matches today: OneTablet does not yet produce that state.Possible values: [open, paused, closedSpecialHours] - hasDiscrepancyboolean
Filter to stores with (or without) a live discrepancy between desired and observed state.
- pagePageRequest
Cursor pagination.
{
"storeIds": [
"<storeIds>"
],
"locationIds": [
"<locationIds>"
],
"brandIds": [
"<brandIds>"
],
"platforms": [
"<platforms>"
],
"state": "open",
"hasDiscrepancy": true,
"page": {
"limit": 50,
"cursor": "<cursor>"
}
}Responses
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.
- statusesStoreStatus[]
The page of statuses, sorted by
storeIdascending. - nextCursorstring
Opaque cursor for the next page. Absent means the last page.
About Store status
Whether each storefront is actually taking orders — and whether OneTablet and the delivery platform agree about it.
Separate from Stores, which is the identity map: the brands, kitchens and storefronts you operate, which changes when your estate changes. This section is the OPERATIONAL layer on top of it — one read (fetchStoreStatuses), two writes (pauseStores, unpauseStores) and the store.status.changed webhook — all addressed by the Store.id values fetchStores hands you. Same api key, same org scoping, same ids; a different job, and a different route prefix (/management/store-status) so the url says which.
Three things are kept distinct throughout, and conflating them is the mistake this section exists to prevent: desired is what OneTablet is configured to do, observed is what the platform reports, and discrepancy is the classified disagreement between the two.
Org-scoped to the organization your api key resolves to, exactly as the directory reads are.