Set location weekly hours

Replace a location's WEEKLY operating hours — the regular template, as opposed to the date-specific overrides setLocationSpecialHours above writes. Send the complete week; windows replaces whatever the location had. A window whose closesAt is earlier than its opensAt crosses midnight, and several windows may name the same day for a split service.

WHAT IT PROPAGATES TO. Every storefront at the location whose menus FOLLOW LOCATION HOURS. A menu configured with its OWN weekly hours is deliberately unaffected — read MenuAssignment.hours.followsLocationHours from fetchStoreMenus to see which is which. So is a storefront of another organization's brand once that organization has set its own weekly hours at your kitchen: its menus that follow location hours take that organization's hours, not yours, and fetchStoreHours keeps reporting them for it. That is narrower than "every storefront on every platform", and it is the narrower statement that is true.

An hours write republishes menus. Propagation is an asynchronous save-then-publish over every affected menu, typically completing within minutes — so a menu holding UNPUBLISHED saved changes goes live with them. Verify the outcome with fetchStoreHours, which reads the effective, post-propagation state; this operation's own reply echoes what was persisted, not what each platform has yet accepted.

windows is required and must be non-empty — see SetLocationHoursRequest for why there is no wipeAll twin of the special-hours escape hatch here.

Scope: owner-only, which is narrower than the reads. Only a locationId your organization OWNS — one whose Location.organizationId from fetchLocations equals your own organization id. If you operate a brand out of somebody else's host kitchen, fetchLocations shows you that kitchen and fetchStoreHours reports the hours its storefronts trade on, but you may NOT write the kitchen's weekly hours: this write moves the weekly template for every brand there that follows the location's hours, including the host's, so it is the host's to make. Ask them, or give your brands their own week instead (below).

A locationId that is not yours — whether another organization's outright or a host kitchen you merely operate in — is INDISTINGUISHABLE from one that does not exist at all. All of them are the same 404 {"message":"Not Found"}, and never a write. The body is deliberately bare: anything that told the cases apart would let you enumerate locations you cannot see. The rule above is the explanation the body does not carry, so check organizationId on the location from fetchLocations against your own organization id before you write.

Your own week at a host kitchen. If your brands cook in somebody else's kitchen, your organization can set its own weekly hours for all of its brands there, in the OneTablet Portal. They apply to your brands there and to nobody else's, fetchStoreHours reports them as regular on your storefronts there whose menus follow location hours, and the host's setLocationHours no longer changes those storefronts' weekly hours. No operation on this API reads or writes that schedule as such.

Safe to retry: this operation changes state but is idempotent.

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".