fetchStoreStatuses
Status for any set of stores — one storefront or the whole estate — in one operation (ONE-2619, v1).
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.
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.
closedSpecialHoursnever matches in v1 — see the note above.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
- 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.
SPLIT OUT OF Stores BY ONE-2736. Stores 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.