Kept menus on /v1/menus
POST /v1/menus now answers from a whole menu Layout already read from the restaurant's own site, when it read that menu recently. These answers come back as a 200 at once: no 202 reading, no polling, and nothing drawn from your allowance. The new optional readAt field says when that read happened. See POST /v1/menus.
What changed
- Recent menus on REST.
POST /v1/menusanswers from a recent read, as the MCPmenutool already did. - No prices, said plainly. When none of a menu's items carry a price,
pricesUnavailableistrueandconfidenceispartial, onPOST /v1/menusand the MCPmenutool alike. Until now a menu with no prices could come back withpricesUnavailable: false. - Asked by name. A menu asked for by restaurant name now finds a recent read of that exact store, the same as one asked for by
placeId.
What to do
Nothing is required. If you show prices, check pricesUnavailable and never fill a missing price in.
Breaking changes
None. Nothing you send changes and no field was removed; readAt is new and optional.