FetchOrdersRequest

Fields

• orderIdsstring[]

  Fetch specific orders. Every other filter is ignored when this is present — the window, the statuses, the kitchen and the storefront. sort and page still apply: they shape the answer rather than narrowing it.

  That has always been what this field says, and as of ONE-2750 it is also what happens. Before it, the filters were combined, so an orderIds call that also carried a stale time window came back missing the ids that fell outside it — a subset indistinguishable from "those orders do not exist". If you were sending filters alongside orderIds and relying on them to narrow, send them without orderIds instead.

• locationCodestring

  One kitchen per call, addressed by its short site code — the code on the Location that fetchStores and fetchStore already report. Omit for every kitchen. An array form may be added additively later.

  ⚠️ REPLACES locationId (ONE-2750). The feed behind this operation filters on the location CODE, and the previous parameter took an id that this service then resolved to a code by making a second call to the store directory — which meant a real kitchen with no storefronts yet answered 404 for a filter that should simply have matched nothing. Taking the code directly removes that call, that failure mode, and one hop from every request. The code is published on every store row, so it is a value you already hold.

  Mutually exclusive with storeId — see that field.

• storeIdstring

  One storefront per call, by Store.id as fetchStores reports it (ONE-2750). Omit for every storefront.

  MUTUALLY EXCLUSIVE WITH locationCode: sending both is a 400. A store is already inside exactly one kitchen, so the pair is either redundant or contradictory, and answering either way would hand you a page whose meaning depends on which filter we decided to honour. Send whichever one you actually mean.

• statusesstring[]

  Filter by stored status. recentlyCancelled is a stored-status filter value that renders as cancelled in responses — pass both to retrieve all cancelled orders.

  Possible values: [new, future, ready, finished, rejected, cancelled, recentlyCancelled]
• createdAtStartDatestring<date-time>

  Inclusive lower bound on the order's CREATION time (Order.createdAt), ISO-8601 UTC.

• createdAtEndDatestring<date-time>

  Exclusive upper bound on the order's CREATION time (Order.createdAt), ISO-8601 UTC.

  NO MAXIMUM WINDOW WIDTH (ONE-2750 removed the 31-day ceiling), and omitting both bounds is legal and means all-time.

• sortstring

  How to order the page, on the order's creation time (ONE-2750). Defaults to createdAtDesc.

  createdAtDesc — newest first. This is what you want for "what has arrived since I last polled", and it is what every OneTablet surface shows a kitchen.

  createdAtAsc — oldest first, which with no cursor is exactly "my very first order".

  The order is TOTAL — ties on createdAt break on the order's id — so a given page of a sweep names the same rows every time you ask for it.

  Possible values: [createdAtAsc, createdAtDesc]
• pagePageRequest

  Cursor pagination.

  ⚠️ THE CURSOR HAS A DEPTH LIMIT ON THIS FEED: 10,000 orders. Past that you get a 400 naming the number. Paging deeper is a backfill, and the answer for a backfill is a narrower [createdAtStartDate, createdAtEndDate) window — which costs you nothing, since there is no limit on how WIDE a window may be. The two together give you every order we hold; what they refuse is the one access pattern that is expensive for both of us.