fetchMenu
The complete menu as one document: categories -> items -> modifier groups -> modifier options.
storeId absent -> base prices, availability flags OMITTED. storeId present -> prices resolve for that storefront's location (see Menu's V1 SCOPE note on MenuPricingRule), availability flags included from live StockItem state.
Scope: a menu whose brand this organization owns, OR that this organization has assigned to one of its own storefronts. An unknown or foreign menuId is NotFound — indistinguishable by design, same as every other directory/menu read on this API.
Request
- menuIdstring
The menu to fetch. Required — an absent value is
404. A menu that does not exist and one outside your organization's scope (neither its brand is yours nor is it assigned to one of your storefronts) are the same404, indistinguishably. - storeIdstring
Optional storefront context: when provided, prices and availability resolve for this storefront; otherwise base prices are returned and availability flags are OMITTED (never defaulted to
false).
{
"menuId": "00000000-0000-0000-0000-000000000000",
"storeId": "00000000-0000-0000-0000-000000000000"
}Responses
- menuMenu
The requested menu document. Always present on a
200; an unknown menu is a404instead.
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.