# Introducing the Images API

October 1, 2026 · API

Layout now finds the photo a restaurant published of any item on its menu and serves it from its own CDN. It is never a stock or generated image.

## What changed

- [POST /v1/images/items](https://developer.layout.link/reference/api#post-v1-images-items) takes an `item` in the person's words and a restaurant by `placeId` or `query`. A photo Layout already holds answers at once. Otherwise Layout reads the restaurant's own site and answers `200` when it finds one within about 12 seconds, or `202` with an `imageId` to poll for free.
- Layout stops looking 35 seconds after your request. A poll after that answers `no_photo` with reason `not_found_in_time`, so a person is never left waiting on a picture.
- Every `/v1/menus` item Layout already holds a photo for carries an `image`, with no extra request and no extra allowance.
- An OAuth connection over MCP has the same lookup as the `item_photo` tool.

## Why it matters

A person deciding what to eat wants to see it. A chain needs no branch and no open store, because its photos are the same everywhere, and the item's spelling and phrasing need not match the menu.

## What to do

Call it with a person credential, the same as places and menus.

Show the `cdn.layout.link` URL rather than copying the file: when a restaurant asks Layout to take its photos down, the URLs stop serving everywhere at once. A search that opens the restaurant's site counts toward a new daily allowance of image searches, 300 in sandbox and 2,000 for an approved production application; a photo Layout already holds never counts. See [limits](https://developer.layout.link/reference/limits#place-and-menu-reads).

## Breaking changes

None. `image` is a new optional field on menu items, and the routes are new.
