# Kept menus on /v1/menus

October 14, 2026 · API

`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](https://developer.layout.link/reference/api#post-v1-menus).

## What changed

- **Recent menus on REST.** `POST /v1/menus` answers from a recent read, as the MCP `menu` tool already did.
- **No prices, said plainly.** When none of a menu's items carry a price, `pricesUnavailable` is `true` and `confidence` is `partial`, on `POST /v1/menus` and the MCP `menu` tool alike. Until now a menu with no prices could come back with `pricesUnavailable: 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.