Reference · built on requestConnectorHospitality & property systems

Toast

Orders, payments, menus, stock, labor, and cash entries from Toast restaurant locations.

Request accessPricing ↗

About

Toast is a restaurant point-of-sale platform. Its APIs are grouped as orders, payments, menus, stock, restaurant info, kitchen, employees, cash entries, analytics, and device details, each scoped to one restaurant by the Toast-Restaurant-External-ID header. Webhooks push order updates, stock changes, and menu changes as they happen.

Through Fibric, an operator follows orders and stock per location and proposes a check update, an order, or a shift record for your approval. Every change is applied once and leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Toast and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders and checks by GUID, or in bulk by date or modification range, through the orders API
  • Order changes through the orders webhook, eventCategory order_updated or channel_order_updated, with the full order JSON minus guest personal data
  • Menus through the menus API, and menu item availability through the stock API and stock webhook
  • Employees through GET /labor/v1/employees, with jobReferences and wageOverrides, plus their time entries and shift assignments
  • Cash deposits and other cash transactions through the cash entries API
  • Restaurant business information through the restaurant info API and prep stations through the kitchen API
  • Menu changes, restaurant availability, and the online ordering schedule through their own webhooks

Proposed actions

  • Target capability: propose an order with menu selections and a dining option through POST on the orders API
  • Target capability: propose adding items, applying a discount, or changing a tip on an existing check through PUT on the orders API
  • Target capability: propose a void on an order through the orders API
  • Target capability: propose a new employee or a shift assignment through the labor API

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch an item going 86

    The stock webhook reports when a menu item becomes unavailable. The operator proposes the online menu change and the note to the floor, and records when the item returns.

    With 86 Watch

  • Balance the floor inside the shift

    Bulk order pulls per location show the pace of checks against employees on the clock through the labor API. The operator proposes a shift change and leaves the reason.

    With Intraday Balance, Labor Budget

  • Reconcile cash drawers

    Cash entries record deposits and other cash transactions per restaurant. The operator flags a drawer that does not tie out and proposes the entry to review.

    With Bank Reconciliation

  • Hold a suspect refund

    Orders and payments show refunds and voids per check. The operator matches them to policy and proposes which ones a manager should approve.

    With Refund Policy

Requirements

  • API credentials for the restaurant: standard API access from the Toast Shop is read-only; read and write needs a custom integration or Toast's integrations program
  • The Toast-Restaurant-External-ID header set to the restaurant GUID on each request
  • The sandbox and production hostnames from the Toast integrations team; standard API access runs only against production
  • Webhook subscriptions set up by Toast support, each with its own secret for message signing
Authentication
OAuth 2 client credentials: POST clientId and clientSecret with userAccessType TOAST_MACHINE_CLIENT to /authentication/v1/authentication/login, then send the token as a Bearer header; tokens expire after the expiresIn seconds in the response.

Limits

  • 20 requests per second and 10,000 per 15 minutes across all APIs; GET /ordersBulk allows 5 per second per location and one-month history windows
  • Ordering channel integrations hold orders:read plus orders.channel:read and retrieve only the orders they submitted
  • API-created orders cannot use open menu items, cash, Toast gift cards, or Toast loyalty; payment types are CREDIT and OTHER
  • Webhooks retry twice, after five and ten minutes, then stop; order payloads can exceed 600 KB

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Toast ↗

Questions and answers

Does Toast send webhooks for new orders?
Yes. The orders webhook fires when a restaurant creates or updates an order; a new order uses the same order_updated event. Guest names, phone, and address are omitted from the payload, so the operator reads the order by GUID for those fields. Toast support creates the subscription.
Can I write to Toast with standard API access?
No. Standard API access from the Toast Shop is read-only and works only against the production environment. Read and write access is for custom integrations built by a restaurant's own developers, or for integrations admitted to Toast's program, which also receive sandbox access.
What are the rate limits?
20 requests per second and 10,000 per 15 minutes, global and per API. GET /menus allows 1 per second per location; GET /ordersBulk allows 5 per second per location. A 429 carries X-Toast-RateLimit-Reset and Retry-After headers that say when to resume.
Ask about Toast

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Toast through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy