fetchOrders

POST/management/orders/fetchOrders

The order feed and single-order read in one operation: filter by time window, statuses, or location — or pass orderIds to fetch specific orders.

from / to bound the order's PICKUP time — from inclusive, to exclusive, maximum window 31 days; page longer history window by window. There is no rolling retention ceiling: a full warehouse backfill is a loop over [from, to) windows.

Cursor-paginated; the response is an object, so new fields can arrive additively.

NOT YET IMPLEMENTED (ONE-2644). The contract, its DTOs and its docs page are real; the server answers 501 until the query behind it lands in ONE-2617 — including the 31-day window rule and the cursor semantics described above, which are documented here because they are part of the published contract, NOT because anything enforces them yet.

Request

application/json

required

orderIdsstring[]
Fetch specific orders; other filters are ignored when present.
locationIdstring
One location per call; omit for all locations. An array form may be added additively later.
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]
fromstring<date-time>
Inclusive lower bound on the order's PICKUP time, ISO-8601 UTC.
tostring<date-time>
Exclusive upper bound on the order's PICKUP time. At most 31 days after from.
pageobject
Cursor pagination.
- limitnumber
  Page size, 1-100. Defaults to 50 when omitted.
- cursorstring
  Opaque cursor from the previous response. Omit for the first page.

{
  "orderIds": [
    "<orderIds>"
  ],
  "locationId": "00000000-0000-0000-0000-000000000000",
  "statuses": [
    "new"
  ],
  "from": "2026-01-01T00:00:00Z",
  "to": "2026-01-01T00:00:00Z",
  "page": {
    "limit": 50,
    "cursor": "<cursor>"
  }
}

Responses

200 — OK

ordersobject[]
The page of orders. Ordering within a window is unspecified and iteration is not snapshot-stable — for exact backfills use contiguous [from, to) windows and reconcile on order id.
- idstring
  OneTablet's identifier for the order (uuid) — the id every other operation takes.
- statusstring
  Current state of the order.
  Possible values: [new, future, ready, finished, rejected, cancelled]
- deliveryStatusstring
  Delivery progress, where the platform transmits it.
  Possible values: [ASSIGNED, EN_ROUTE_TO_STORE_LOCATION, EN_ROUTE_TO_CUSTOMER, COMPLETED, CANCELED]
- createdAtstring<date-time>
  When the order record was created, ISO-8601 UTC.
- updatedAtstring<date-time>
  When the order record last changed, ISO-8601 UTC.
nextCursorstring
Opaque cursor for the next page. Absent means the last page.

About Orders

Orders placed with your restaurants — read them, and act on them.

This is where an integration starts: poll fetchOrders for the orders OneTablet has accepted on your behalf across every delivery platform you are connected to, normalised into ONE shape regardless of whether they arrived from DoorDash, Uber Eats, Grubhub or a direct channel.

Two conventions hold everywhere on this API and are worth learning once. Money is always an integer in the currency's minor unit — 1250 is $12.50 — because a decimal total cannot survive a round trip through every language's default number type. Times are always ISO-8601 in UTC; a store's local time is a rendering decision, and the API does not make it for you.

All endpoints are POST with a single JSON body, and the path carries no version segment: evolution here is additive — new fields and new endpoints, never removals or narrowing (ONE-2596) — so there is no cutover a /v1 would ever mark.