Toast API and LOCAL: what you can take and where the line is

The verdict in three points

Toast, for roughly $25 per location and in a single day, covers the bottom three layers of LOCAL. Menu with modifiers, hours, seating zones, the stop list, the status of online order acceptance, plus webhooks that keep all of it fresh without any effort on our side.
And it does not expose the fourth layer, where the money lives. Reservations and tables are not in the API at all: Toast Tables has no reservation book read, and clients have an open request for one in the official community. Admission rules do not live there either, because that is a human decision, not data.
So the question is not "to take access or not to take it" but "to take it as a cheap foundation and build the product where the API does not reach". There is nothing to sell in pure reading: open wrappers over the Toast API are already on GitHub and plug into ChatGPT by link.

~180 000locations on the platform, 30.06.2026

~20%of the US restaurant market, Toast's own estimate

$215Bpayment volume over 12 months

4doors into Toast, one of them open to us

~$25per location per month, an estimate, not a Toast price

1. Why start with Toast

This is a POS for US restaurants and the largest player in its segment. Every fifth independent restaurant is already inside, growth of 22 percent year over year against an almost flat market, meaning Toast is taking share rather than riding a wave.

Metric	Value	Date and source
Live locations on the platform	~180 000	30.06.2026, company disclosure
Share of the US restaurant market	~20%, it was 4-5% at IPO	company statements, 2026
Payment volume over 12 months	~$215B	30.06.2026, company disclosure
Location growth	+22% year over year	second quarter 2026 reporting

Practical conclusion

Our first group of clients is almost guaranteed to be on Toast, and we do not need to explain what it is. Starting with one POS makes sense for exactly this reason, rather than with a zoo of six platforms.

2. Four doors, and one of them is open to us

To read data out of Toast we do not need Toast's permission and we do not need partner status. We need a client with a Restaurant Management Suite Essentials subscription or higher, the Manage Integrations right on their locations, and the purchase of an add-on in the Toast Shop. The client creates the credentials themselves in their own account, within a day, and hands them to us.

Integration type	Who opens it	Read	Write	Price	Our status
Partner	Toast, via an application and certification	yes	yes	not published	only if we apply and pass
Custom	the client themselves via their account manager	yes	yes	not published	the client can, we as a vendor cannot
Standard API access	the client themselves, by purchasing in the Toast Shop	yes	no	~$25 per location per month, an estimate	this is our door
Analytics API	the client themselves, included in RMS Pro	yes, reporting	no	part of the subscription	available, but that is reports, not a product

The flip side of the same fact

The access belongs to the client, not to us. The client leaves, the access leaves. This is a rental, not an asset, and it has to be said out loud rather than pretending the API is ours.

3. What can actually be taken

All calls are read-only, and all are tied to a single location: for a group of 40 sites that means 40 separate requests.

API	What is inside	What it gives LOCAL
menus v2	Expanded menu: groups, items, sizes, modifiers, prices	The main layer. The composition of a dish and what can be removed or swapped
configuration	Seating zones, revenue centers, payment methods, order options	Half of the admission rules: which zones and order types exist
restaurants	Name, address, opening hours, schedules	Stable attributes that nobody keeps fresh
restaurant availability	The status `ONLINE` or `OFFLINE` and the reason: whether the site is accepting online orders right now	The only perishable fact Toast exposes to the outside. But that is about online orders, not about tables
stock	Stock by item and modifier, what has run out	"Is this dish available today" without a phone call
orders	Orders, checks, payments, history	Indirectly. Almost nothing for answering a guest
partners	Which locations the client has access to	Technically needed: it shows the coverage of the group
labor, cashmgmt, kitchen, packaging, device-details	Shifts, cash, kitchen, packaging, devices	Internal, useless for the product

Webhooks are what keeps the data fresh

The client can subscribe to events themselves, and changes arrive to us immediately. Available categories: menus, stock, orders, the guest's order fulfillment status, location availability, packaging, partners, the online ordering schedule. For LOCAL three matter: menus, stock and availability. That is also the answer to the objection "the data rots" for the portion of facts that exists in the system at all.

4. The limits you need to know before promising anything to a client

Limit	Value	What it means in practice
Overall limit per client	20 requests/s, 10 000 per 15 min	At full tilt the fifteen-minute window is used up in 8 minutes 20 seconds and then you sit idle
Limit per specific API	20 requests/s, 10 000 per 15 min	There is no separate reserve
Menu	1 request/s per location	A menu across 40 sites takes minutes to collect. Caching is mandatory
Order history	5 requests/s per location	History intervals of no more than a month, calls 5-10 seconds apart
Credential sets	up to 100 per management group	Enough, but it is a resource that has to be maintained
Sandbox	none, production only	We test on a live restaurant, a mistake is visible immediately

5. What is not in the API, and that matters more than what is

What is missing	The fact	The consequence for LOCAL
Reads of reservations and tables	Toast Tables exists as a product, but there is no reservation book read in the API. In the official developer community there is an open request from a multi-location client specifically for reading reservations. The existing reservations integration works for writing only: `POST /orders` when a guest registers. Reservations are not in the webhook list either.	"Is a table for eight free on Friday" cannot be obtained through Toast. The product "get the guest to the table" cannot be built on reading
Admission rules	Allergens, diets, the private room, the deposit, the minimum check, age restrictions after a certain hour	This is operational policy, not data. The layer is assembled by hand, once, together with the venue. And this is exactly what people pay for
Writes	Without a partner integration only `GET` is available	We cannot create a reservation, an order or change a status. At most: read and hand back an answer
Cross-location requests	All requests are per single location	Network, cache and limits are counted per group, that is engineering work
Ready-made wording for a guest	Identifiers and structures come back, not human phrases	The language of the answer is our layer

6. LOCAL's four layers against what Toast can do

four layers of local information: which of them Toast covers

LOCAL layer	Examples	What Toast gives	Who covers it	Lifetime
1. Existence	The venue exists, address, category	Name, address, location status	Toast plus public sources	years
2. Stable attributes	Hours, zones, payment, order types	Hours, schedules, zones, payment, order options	Toast covers almost all of it	months
3. Operational facts	Today's menu, dish composition, the stop list, whether they are taking orders	Menu with modifiers, stock, online order status, webhooks	Toast covers it, and with fresh data	days and hours
4. Perishable	A table for eight, gluten-free, the private room, the deposit, a quiet courtyard	Almost nothing	People only: the owner confirms once, we hold it and date it	hours and days

What this table shows

Toast covers three of the four layers, that is, everything that is cheap and does not involve us. It does not cover the fourth, where the money lives, and it cannot, because there the thing is not data but a human decision: "yes, I will seat this party at eight, and yes, without garlic". The product begins exactly where the API ends.

7. Three options for a relationship with Toast

Option	What we do	What we get	Risk
Read	We install on the client's credentials, read the menu, hours, zones, the stop list, order status, and webhooks keep it fresh	Onboarding a group in a day instead of a week of field work	Commodity. Open wrappers over the Toast API sit on GitHub and plug into ChatGPT by link
Augment	On top of what is readable we assemble the admission rules and the owner's confirmations with dates	A product that cannot be copied over a weekend: the rules sit with people, not in the API	The rules have to be maintained: confirmed, re-checked, marked with an expiry date
Write	Through a partner integration we get the right to create a reservation or an order	The assistant carries the guest through to the table, not just answers	A formal application and certification. They say no, and the layer does not exist at all

8. Where we are an add-on, where a competitor, where dependent

Add-on. Toast will not answer an assistant on behalf of the venue and will not publish admission rules. That is not its job, it sells a POS and payments. We sit on top.
Competitor for budget. For a line in the budget we compete not with Toast but with what is already being paid for: the person answering the phone, the waitlist, marketing. Part of the layer the owner already pays for in the POS subscription.
Dependent. Access is rented from the client, writing depends on the partner program, cross-location work runs into the limits. We depend on the client and on Toast at the same time.

9. The economics on this foundation

Line item	Value	Comment
Access per location	~$25 per month, an estimate	The client pays it, not us. So our price has to be above this line
Freshness of layers 1-3	almost zero marginal cost	The main economic victory: what used to cost a field visit now arrives on its own
Freshness of layer 4	person-hours	That is where our cost lives, and it does not fall with scale as fast
What we charge a group	$2 500-5 000 setup plus $79-99 per location per month	The floor has to be noticeably above $25, otherwise the budget conversation ends at the first meeting

10. Three scenarios for a first product

A reading layer for a group. The client's credentials, their menu, hours, zones, stop list and order status go to the assistant. The value is real, there is almost nothing to maintain. Death: within 60 days no group has paid more than $25 per location, because they get the same thing themselves.
A rules layer on top of reading, our main path. To what is readable we add allergens, diets, private rooms, deposits, minimum check, late evening, the quiet courtyard. The owner confirms once, we hold the record with a date and an expiry. Death: after 20 conversations with named groups not a single pilot is signed for money.
Partner writing, slow and protected. The write right makes the assistant the one that carries the guest through to the table. Death: a rejection on the application, or requirements on timelines and volumes that two people cannot carry.

Practically: the second scenario as the product, the first as a way to get to know a group over a single webhook, the third as a decision after the first money, not before.

11. What to verify rather than assume

The right to resell: whether the partner agreement allows using access issued to a client for providing services to that client and their partners.
Write scopes: whether Toast grants the write right to a vendor working on the credentials of someone else's locations, and what security requirements come with it.
Whether Toast Tables exposes anything at all through webhooks. If not, the reservations topic is closed for good.
The real volume of non-standard requests to assistants: no one has a public number, and without it layer four remains a bet.

12. Sources

Toast: API overview, the full list of APIs and the methods available for each integration type.
Toast: integration types and Standard API access overview: read without write, no sandbox, a separate request per location.
Toast: Standard API scopes, the full list of available read scopes.
Toast: rate limiting, the values of 20 per second and 10 000 per 15 minutes, the separate limits for menu and order history.
Toast: webhook subscriptions and webhooks reference, the list of event categories.
Toast: partner integration overview, the formal application and certification, the read and write right.
Toast: analytics API access: included in RMS Pro, read only.
A request in the Toast community for read access to Toast Tables reservations, as well as the POST /orders write used when a guest registers.
Toast Tables: what the reservations and waitlist product does.
The scale of the platform: company disclosures and 2026 conferences (on the order of 180 000 locations as of 30.06.2026, about 20 percent of the US market, $215B in volume over 12 months).
Open wrappers over the Toast API: prime-cost/toast-mcp, atthewm/toast-mcp-server, BusyBee3333/toast-mcp-2026-complete.

Method and honesty

Everything is taken from Toast documentation and open sources, with dates given wherever they are available. The single estimated value is marked: the Standard API price of around $25 per location per month comes from secondary sources, Toast does not publish a price for this line. The unverified is called unverified: how many guests actually ask assistants perishable questions, and what the partner agreement says about resale, I do not know.

Toast API:what you can take and where the line is