fetchStoreMenus
Which menus are assigned to each of up to 100 storefronts (ONE-2622, Phase 1), each menu's operating-hours configuration, whether and when it was last published, and — where a published snapshot exists — the menu document exactly as last published to that storefront.
Snapshots are returned verbatim from OneTablet's publish history, never regenerated; a menu never published to the store carries no snapshot, and neither does one whose recorded snapshot exceeds this API's size cap (see MenuAssignment.snapshot's doc comment).
No pagination — pass 1-100 storeIds and chunk a larger estate across calls.
Request
- storeIdsstring[]
{
"storeIds": [
"<storeIds>"
]
}Responses
- assignmentsobject[]
- storeIdstring
- menusobject[]
- menuIdstring
- namestring
- isPublishedobject
- lastPublishedAtstring<date-time>
- hoursobject
- followsLocationHoursobject
- windowsobject[]
- snapshotobject
The published menu document, verbatim — arbitrary JSON, not typed by this contract.
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.
All three reads are org-scoped to the organization your api key resolves to, and all three are reads: nothing here mutates, and nothing here calls out to a delivery platform live (ONE-2618).