llms.txt

Who this is for: a crawler or model building an index customers ask questions of. storekit ordering pages are a client-side app, so a crawler that does not run JavaScript sees an empty document. Every ordering host also serves plain-text descriptions following the llmstxt.org convention, rendered from the same data the pages use.

Paths

Path	Answers with
`GET /llms.txt`	On a brand’s own domain, that brand’s file. On the shared ordering host, what the host is and where a store’s own file lives.
`GET /{venueSlug}/llms.txt`	One venue: summary, ordering methods, address, opening hours, contact details and policies.
`GET /{venueSlug}/llms-full.txt`	The same, plus the full menu — every category, item, price and dietary tag.
`GET /b/{brandSlug}/llms.txt`	A brand and its locations. `/stores/{brandSlug}/llms.txt` serves the same file.

Responses are text/plain, cached for 15 minutes at the edge. A venue or brand that does not resolve is a 404; a brand that resolves with no locations taking orders still returns a file, saying so. A venue file is Markdown-shaped: an H1 with the venue name, a one-line summary, then ## Ordering, ## Location and opening hours, ## Contact, ## Menu on the full file, ## Policies and ## Notes. A very long menu is truncated with a note pointing at the menu page.

These files are a snapshot for reading, not a source of truth for ordering. Availability and opening state change during service, and a crawler’s copy will be stale — an agent that needs a current answer should use the MCP endpoint.

The host’s robots.txt allows the agent crawlers by name, so these paths and the UCP profile are unambiguously open to them.

Developers

Guides

Ordering Agents

Webhooks

Paths

​Paths

Paths