Publish a menu

POST/management/menus/publishMenu

Push the menu's current SAVED state to the delivery platforms.

Saving a menu never changes what guests see — this call does, and there is no unpublish.

Asynchronous. The reply is an acknowledgement carrying a publicationId; per-store, per-platform outcomes arrive from fetchMenuPublications and on the menu.publication.completed webhook. A failed store carries the platform's error verbatim where the platform provides one — some platforms report only success/failure.

WHAT IS SENT. A publication always submits each storefront's COMPLETE menu set, because platforms replace rather than merge. menuId therefore selects WHICH storefronts are published to, not what they receive: publishing menu A to a storefront that also carries menu B re-submits BOTH. See MenuPublication.menuId for how that surfaces on the read side.

Scope: menuId must resolve under this organization by the SAME predicate fetchMenu uses, and every storeId supplied must be a storefront this organization owns. Anything else is 404 with NOTHING published — never a partial write, and never a distinction between "does not exist" and "not yours".

NOT safe to retry: this operation changes state and is not idempotent.

Request

application/json

required

menuIdstring
The menu to publish. Required — the published schema lists it under required: [menuId], and this API returns 404 for a menu that does not exist AND for one belonging to another organization, indistinguishably.

WHAT THIS SELECTS. menuId chooses WHICH STOREFRONTS are published to (the ones it is assigned to); it does not narrow WHAT is sent to them. Each selected storefront receives its COMPLETE active menu set, because delivery platforms replace rather than merge — see the operation's own doc comment.
storeIdsstring[]
Narrow the publication to specific storefronts. Omit to publish to EVERY store the menu is assigned to — the published description's own wording.

A storeId here that this organization does not own, or that the menu is not assigned to, is 404, and NOTHING is published: the request is rejected whole rather than silently applied to the subset that did resolve. A partial publish a partner did not ask for is worse than a rejected one, because there is no unpublish.

{
  "menuId": "00000000-0000-0000-0000-000000000000",
  "storeIds": [
    "<storeIds>"
  ]
}

Responses

200 — An acknowledgement carrying the `publicationId` to follow the publication by.

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.

publicationIdstring
Poll this with fetchMenuPublications({ publicationIds: [publicationId] }).
statusstring
Always queued on success: the publication was accepted. Follow its progress with fetchMenuPublications.
Possible values: [queued]

About Menus

Menus — read a menu, publish it to the delivery platforms, and follow each publication's per-store, per-platform outcome.

publishMenu is the only write here and the only operation on this API that changes what guests see on live DoorDash, Uber Eats and Grubhub storefronts. There is no unpublish.

Every operation is scoped to the organization your API key belongs to. An id that does not exist and one that belongs to another organization are the same 404, indistinguishably — and on publishMenu a menu or store outside your organization is rejected before anything is published.

Retries create a second publication. publishMenu does not replay a previous result: a retried call creates a new publication with its own publicationId and re-submits to the platforms. That changes no content — a publication is a full replace of the same saved menu — but it doubles platform traffic. Treat a timeout as "may have succeeded" and check fetchMenuPublications before retrying.