List items for a store
The item catalogue for ONE STOREFRONT — the per-store form of fetchLocationItems, for a partner holding store ids from fetchStores rather than kitchen ids.
Availability is held at the kitchen, not the storefront. This operation resolves your storeId to its parent kitchen and answers from there, narrowed to the store's own brand. Two consequences worth designing against, both of them properties of the platform rather than of this API:
availableis the KITCHEN's answer. Every sibling storefront of the same brand at that kitchen reports the identical value, and 86-ing an item affects all of them. The reply echoeslocationIdso the sharing is visible in the data, not just in this paragraph.availableis what OneTablet INTENDS, never what the delivery platform currently shows. A platform can independently mark an item unavailable on its own side, and this read does not see that. It is the item-level counterpart of thedesired/observedsplitfetchStoreStatusmakes explicit for the storefront itself.
A storefront being PAUSED is a separate axis again and does not change any available value here — read fetchStoreStatus for that.
Scope: the store must be one this organization owns or operates a brand out of, and items are restricted to the store's own brand. An unknown or foreign storeId is NotFound, indistinguishable by design.
Safe to retry: this operation is read-only and idempotent.
Request
- storeIdstring
The
Store.idwhose catalogue you want. - querystring
Case-insensitive name search.
- availableboolean
Filter to items currently available (or unavailable) at the store's kitchen.
- pagePageRequest
Cursor pagination.
{
"storeId": "00000000-0000-0000-0000-000000000000",
"query": "<query>",
"available": 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.
- asOfstring<date-time>
When this response was assembled — UTC, ISO-8601. The availability values are read live at that moment; this is the freshness claim for the whole response.
- locationIdstring
The kitchen the answer actually came from.
Read this before acting on the result. Availability is held at the KITCHEN (location) grain, never per storefront, so this operation resolves your
storeIdto its parent location and reports that kitchen's catalogue. Every sibling storefront at the same kitchen sees the identical answer. Echoed here so the sharing is visible in the response rather than only in the documentation — pass it tosetItemAvailabilityif you intend to change anything. - itemsItemAvailability[]
The page of items tracked at the store's kitchen, narrowed to the store's own brand and sorted by name. Empty when nothing matches.
- nextCursorstring
Opaque cursor for the next page. Absent means the last page.
About Item availability
Item availability ("86-ing") — mark one item available or unavailable at one kitchen.
fetchLocationItems and setItemAvailability work as a pair: the write needs the discovery read, because OneTablet's item ids cannot be known in advance.
There is no Idempotency-Key replay on this API: a retried setItemAvailability call re-applies the same value rather than de-duplicating.