Running on Toast: what to ask before you add an operations agent

Before any agent goes next to Toast, ask your Toast rep three things: which events you can subscribe to, whether your access can write, and how a token expires. We build the agent beside Toast, reading orders and menus in shadow mode first. The Proof is from 1,500 euro and takes 5 working days.

We are not a Toast partner. What follows about Toast comes from Toast's own developer guide.

What Toast's docs say

• Four ways in. Toast's guide names partner integrations, custom integrations, standard API access and analytics API access.
• Partners read and write. Toast says partner integrations read and write data for the restaurants they share with Toast. Getting there takes an application, a signed partner agreement, sandbox work and a certification call before Toast lists the integration.
• Standard API access is read-only. Toast says a restaurant buys it through the Toast Shop. It needs the Restaurant Management Suite at Essentials or higher and an active employee with the Manage Integrations permission. It has no write access and no sandbox.
• Orders. Toast's guide says you can fetch an order by its ID, orders changed in a date range, or orders for one business date. Each order holds checks with items, modifiers, discounts, taxes and payments.
• Menus. Toast says the menus API returns the full menus, with a metadata call that tells you whether your copy is stale.
• Events. Toast says webhook subscriptions need standard API access and cover menus, orders, packaging preferences, restaurant availability, the online ordering schedule and stock.
• Tokens. Toast's guide says a token is valid for one day, a new one can't be requested until the last minute before expiry, or you authenticate again once it has expired, and one cached token should serve all locations.
• Limits. Toast states 20 requests per second and 10,000 requests per 15 minutes, and suggests the orders webhook over polling.

Questions for your Toast rep

1. Which access type fits us: standard, custom or partner? 2. Which webhook events can our credentials subscribe to, and at which locations? 3. Can anything write? If the agent should mark a dish sold out or fix an order, which route allows that, and what review does Toast ask for? 4. Who holds the credentials, and what happens when that employee leaves? 5. How does a token expire, and do limits count requests across all our locations? 6. Do we need guest details at all? Toast's guide lists a separate scope, guest.pi:read, that adds guest details to the Customer object in the orders API. We ask for the fewest scopes the job needs.

What we build next to Toast

On the access your group already holds, our engineers build an agent that reads orders and menus and compares them with the delivery apps. It flags orders that never reached the kitchen and menus that disagree. In the Proof it runs in shadow mode: it reads and reports, and writes nothing. Writes come in the Pilot, from 6,000 euro over 30 days, live against a baseline you agree first, only through routes your Toast access allows, each one logged with an undo. You own the code.

The Proof path

On day 1 we fix the scope and write 3 to 5 pass/fail tests with you. The Proof takes 5 working days and costs from 1,500 euro, credited in full against a Pilot booked within 30 days. Half is paid up front, the other half when it passes the tests. If it fails and we can't fix it within 5 working days, the first half comes back.

A worked example, on synthetic data

The Europe version of our demo has Toast among its tills. Every order in it is made up. On 7 replayed days, 249 planted incidents, it scored precision 0.98 and recall 0.99. It handled 95% without a person and handed 5% to a person, with the evidence attached. Those numbers are against faults we planted. Your Proof is graded by your own tests, on your own orders. The write-up has the detail.

Send us the job in the form below and a plan with a fixed price comes back within 24 hours.