fetchMenuPublications
Per-store, per-platform publication outcomes — by publication id (the polling path after publishMenu) or filtered by menu or store.
acknowledged and confirmed are DISTINCT states, never collapsed: acknowledged means the platform accepted the submission; confirmed means the platform reported the menu live. confirmationMode says which a given platform is capable of reporting — see that field.
Scope: publications (PublishJob rows) this organization owns. Reads the SAME publication history the OneTablet portal's own "publish menu" flow already writes.
Paging: sorted by request time descending, at the PUBLICATION grain. Loop until nextCursor is absent.
Request
- publicationIdsstring[]
Return only these publications (the
publicationIdvaluespublishMenureturned). Absent means no filter on publication. - menuIdsstring[]
Return only publications that submitted at least one of these menus to at least one store. A matching publication still returns ALL of its stores. Absent means no filter on menu.
- storeIdsstring[]
Return only publications that touched at least one of these storefronts. A matching publication still returns ALL of its stores, not only these. Absent means no filter on store.
- pagePageRequest
Cursor pagination, at PUBLICATION grain.
{
"publicationIds": [
"<publicationIds>"
],
"menuIds": [
"<menuIds>"
],
"storeIds": [
"<storeIds>"
],
"page": {
"limit": 50,
"cursor": "<cursor>"
}
}Responses
- publicationsMenuPublication[]
The page of publications, newest first.
- nextCursorstring
Opaque cursor for the next page. Absent means the last page.
About Menus
Menus — two reads (ONE-2726) and one write (ONE-2780), the section's full published surface.
publishMenu is the ONLY WRITE here and the only operation on this whole API that reaches live DoorDash / UberEats / Grubhub storefronts. There is no unpublish. ONE-2724 once held it behind an undocumented header; ONE-2908 removed that, so today the only thing standing in front of it is authentication plus the org scope check below. It is still absent from MANAGEMENT_API_READ_METHODS in ManagementApiKeyHook, on purpose — that list is now the platform's read/write CLASSIFIER (ONE-2890, ONE-2718 build on it), and a write on a read list would be a lie. Do not "fix" that by adding it.
All three operations are org-scoped to the organization the api key resolves to. Cross-tenant and unknown ids are INDISTINGUISHABLE by design — every one of the three returns the published 404 shape for both cases, same convention as StoresApi / ItemAvailabilityApi. On publishMenu that rule has teeth beyond information disclosure: a foreign menuId must never become a write, so the scope check runs BEFORE anything is enqueued.
NOT IMPLEMENTED: replay via Idempotency-Key. The published contract declares the parameter on publishMenu, and nothing on the platform implements idempotent replay today — the same honest gap ItemAvailabilityApi's header records for setItemAvailability (ONE-2621 decision 3). ⚠️ IT MATTERS MORE HERE: a retried publishMenu creates a SECOND publication and re-submits to the platforms rather than returning the first result. That is not corrupting — a publication is a full replace of the same saved state, so the second is a no-op in content — but it doubles platform traffic and produces two publicationIds for one intent. Callers should treat a timeout as "may have succeeded" and check fetchMenuPublications before retrying.