Skip to main content
Proposal — not implemented in XMART_BACKOFFICE yet. This tab documents a design, not a live contract. Nothing here should be built against until it ships. Today, menu.updated is the only way Fire publishes menus, and it carries the full catalog on every event.

​
Objective

menu.updated sends the complete menu — every category, product, and modifier group — on every publish. That’s simple to consume, but it means a store with a large catalog pays the same payload size for a one-line price change as for a full re-publish, and every subscriber gets data it may not have asked for. Hybrid delivery splits the same information into two steps:
  1. A notify webhook — menu.list_ready — tells your system a menu is ready to be read, with just enough ids to identify it. No catalog data.
  2. An on-demand fetch — GET /v1/menus/{syncId} — your system calls this when it actually needs the menu, using the syncId from the notify event.

​
Scope

This pattern is scoped to menus only. menu.updated keeps working exactly as it does today, indefinitely — this is an alternative, not a replacement. Pick whichever fits your integration:

​
Catalog of methods

​
Delivery

menu.list_ready is delivered exactly like every other Fire webhook — same mechanism, just a lighter body. Fire posts it as application/json to the endpoint you configure per integration from the dashboard (Aggregators → Developer tools → Aggregator integrations), for example https://yourapp.com/webhooks/menu-list-ready. There’s no new delivery channel here, just a new event type.

​
Request headers

GET /v1/menus/{syncId} authenticates differently — your system calls Fire, so it needs an API credential instead of a signature. See Authentication on that page.