Get store hours
Effective operating hours for up to 100 storefronts at a time: regular weekly windows plus special dates (holidays, early closes), resolved in each location's timezone. Windows may cross midnight. Compare against your own expected hours to detect drift.
A storefront whose active menus ALL carry their own hours reports the union of those menus' windows as regular; otherwise the location's weekly hours are reported.
One exception. An organization whose brands cook in a kitchen it does not own can set its own weekly hours for all of its brands there, in the OneTablet Portal. Once it has, those hours replace the location's in regular on its storefronts there. The location's special dates still reach those storefronts: a closure still closes them, and a date that opens the kitchen opens each one only within the hours it reports as regular. Whoever reads those storefronts gets this same answer, the kitchen's owner included: on them, regular is not the week the owner set with setLocationHours.
No pagination — pass 1-100 storeIds and chunk a larger estate across calls.
Safe to retry: this operation is read-only and idempotent.
Request
- storeIdsstring[]
Store.idvalues to read hours for, 1-100.
{
"storeIds": [
"<storeIds>"
]
}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.
- hoursStoreHours[]
One entry per requested storefront your organization operates. Requested ids that are unknown, deactivated or not yours are omitted rather than reported as errors.
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".