Introducing the Images API

October 1, 2026API

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 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.

curl https://api.layout.link/v1/images/items \
  -H "Authorization: Bearer $LAYOUT_PERSON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "item": "iced latte", "query": "Layout test kitchen" }'

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.

Breaking changes

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

All changes