Platform APIs

Layout is an ordering layer, and the point of a layer is that other products can sit on it. If you are building something where somebody might want food, the ordering part should not be a six month integration project with a thousand restaurants.

That is what the platform APIs are for. They are not open yet.

What is coming

Layout Places API. Restaurants that exist, resolved and deduplicated, with the details you need to show one: name, address, hours, coordinates, and whether Layout can order from it. This is the same registry our own surfaces read.

Layout Orders API. Ordering itself: resolve a restaurant, read a live menu, build a priced cart, confirm, and place. The same capability the connector exposes, on a versioned contract with keys, scopes and quotas, at api.layout.link.

Both sit on the same core the connector uses. There is exactly one implementation of each capability here, which is why a partner surface and a consumer one cannot drift into behaving differently.

What exists today

The MCP connector, which is live and documented in trust and security. If you are building on an assistant that speaks MCP, you can use Layout today by turning on the connector and you do not need us for anything.

Everything else on this page is not shipped. There are no keys to issue yet and no endpoints to point you at, and we would rather say that than publish a reference for something you cannot call.

If you want to build on it

Tell us what you are building. Early access goes to the integrations we understand well enough to support, and the fastest way onto that list is a specific description of what your users would ask for.

What we will not change under you

When the APIs open, the public contract is versioned and stable. Internal and consumer surfaces move faster behind it, which is the arrangement that lets us keep improving the ordering engine without breaking somebody's product on a Tuesday.