OVERALL CONTROL / 0.6-customer-control
Grades and scoring
Data access
25% of the overall score before applicability adjustment.
Scored answers and evidence
Read interface 7.5/10
Structured API for the declared product scope
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
The Orders API returns structured orders with checks, selections, amounts and payment references for authorized restaurants. Standard access is read-only; guest details depend on order channel and granted scopes. This assessment covers restaurant order records, not every Toast service.
Toast retrieve multiple orders ↗
GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fields · Checked 2026-10-17
Toast Standard API access ↗
Standard API access overview; read-only access and location selection · Checked 2026-10-17
Toast Standard API frequently asked questions ↗
GET-only access; guest information limitations for in-store versus takeout/delivery orders · Checked 2026-10-17
Bulk delivery 8.8/10
Batched or iterable API requests
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Traverse /ordersBulk pages across bounded modified-date or business-date windows to retrieve scoped order records. This is an API extraction into an integration-owned store, not a delivered database replica or a verified complete POS backup.
Toast retrieve multiple orders ↗
GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fields · Checked 2026-10-17
Toast detailed order extraction guide ↗
Modified-date extraction versus businessDate; pageSize up to 100 and Link pagination · Checked 2026-10-17
Query expressiveness 8.8/10
Documented structured API filters
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Orders support modified-date ranges or a businessDate filter and paginated results. These are fixed order filters; the documented route does not establish general SQL over Toast.
Toast retrieve multiple orders ↗
GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fields · Checked 2026-10-17
Toast detailed order extraction guide ↗
Modified-date extraction versus businessDate; pageSize up to 100 and Link pagination · Checked 2026-10-17
Access cost barrier 5.0/10
Higher plan, separately licensed add-on or fixed recurring access fee
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
For the Standard read route, every participating location needs an active RMS Essentials or higher subscription, obtained separately from Toast Shop. This establishes a recurring access requirement, without a verified amount. Partner/custom write fees and regional commercial terms remain separate and unresolved.
Toast Standard API access requirements ↗
Active employee, Manage Integrations permission and RMS Essentials or higher at every location · Checked 2026-10-17
Toast Standard API access ↗
Standard API access overview; read-only access and location selection · Checked 2026-10-17
Third-party accessibility
20% of the overall score before applicability adjustment.
Scored answers and evidence
Third-party eligibility 5.0/10
Separate provider consent or partner agreement required
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
A restaurant can create Standard read credentials and securely share them with its development team. A chosen partner needing production writes follows Toast application, agreement and certification; a bespoke trusted developer requests custom access through a Toast representative. Customer read credentials do not bypass those write gates.
Toast Standard API credentials ↗
Create credentials; location and scope grants; secure sharing, rotation and revocation · Checked 2026-10-17
Toast partner integration development process ↗
Partner application and agreement; certification; production credentials; geography expansion · Checked 2026-10-17
Toast custom integration overview ↗
Restaurant development teams and trusted technology partners; request access through Toast representative · Checked 2026-10-17
Downstream permission 7.5/10
Published purpose and confidentiality boundaries
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
The API terms recognize merchant ownership of business data and permit merchant-consented AI processing within the integration purpose and onward-disclosure duties. Training or improving models using API-passing data, including synthetic derivatives, requires Toast prior written approval. This finding covers merchant-directed operations and analysis, not unrestricted redistribution or training.
Toast API Terms of Use ↗
Updated June 23, 2026; sections 2.1, 4.2-4.3, 5, 11.1-11.2 and 11.6 · Checked 2026-10-17
External action
15% of the overall score before applicability adjustment.
Scored answers and evidence
Write interface 7.5/10
Create and update in one business domain
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Approved credentials with appropriate order scopes can POST a new order and POST selections to an existing order check. These are documented order creation and modification operations, with restaurant authorization and provider validation. Standard API credentials cannot write; payment execution and arbitrary order deletion are outside this assessment.
Toast create an order ↗
POST /orders; restaurant header; persisted Order response and validation errors · Checked 2026-10-17
Toast add items to an order check ↗
POST /orders/{orderGuid}/checks/{checkGuid}/selections; add selections to an existing check · Checked 2026-10-17
Toast API scopes ↗
Orders API read/write scopes and channel-scoped access · Checked 2026-10-17
Toast Standard API access ↗
Standard API access overview; read-only access and location selection · Checked 2026-10-17
Custom application path 5.0/10
Approved third-party applications using fixed interfaces
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Toast supports customer-developed integrations and approved partner applications on fixed APIs. Production partner credentials follow provider certification; custom write access is requested through Toast. The self-service Standard read route does not establish an unreviewed public write application.
Toast partner integration development process ↗
Partner application and agreement; certification; production credentials; geography expansion · Checked 2026-10-17
Toast custom integration overview ↗
Restaurant development teams and trusted technology partners; request access through Toast representative · Checked 2026-10-17
Toast Standard API access ↗
Standard API access overview; read-only access and location selection · Checked 2026-10-17
Continuity
15% of the overall score before applicability adjustment.
Scored answers and evidence
Refresh mechanism 7.5/10
Documented updated-since filters or webhooks
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
The order collection accepts modification-time windows, including new orders, and order webhooks announce new or updated orders. Use authorized REST reads for fields omitted from webhook payloads, including protected guest details. Events are refresh hints rather than proof of retained event replay.
Toast detailed order extraction guide ↗
Modified-date extraction versus businessDate; pageSize up to 100 and Link pagination · Checked 2026-10-17
Toast order webhook reference ↗
order_updated payload, event identity and omitted guest information · Checked 2026-10-17
Toast Standard API webhook subscriptions ↗
Manage Integrations permission; webhook endpoint, secret and event subscription configuration · Checked 2026-10-17
Limit visibility 10.0/10
Published numeric quotas and recovery instructions
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Default limits are 20 requests/second and 10,000/15 minutes, generally per client and restaurant when the restaurant header is present. ordersBulk additionally allows 5/second; historical windows are at most one month with calls spaced 5-10 seconds. Rate-limit/reset headers and 429 Retry-After support recovery; account-specific exceptions require separate confirmation.
Toast API rate limiting ↗
Global and per-API limits; ordersBulk limits; historical extraction; X-Toast-RateLimit headers and Retry-After · Checked 2026-10-17
CDC and deletion capture 7.5/10
Updates and deletion identities documented for the stated resources
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Order and check payloads expose deletion flags and dates, while order/selection payloads expose void state. Re-read modified windows and preserve those identities and states. These are soft-delete and void signals for returned orders; permanent purges, intermediate versions and ungranted records are not proved recoverable.
Toast retrieve multiple orders ↗
GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fields · Checked 2026-10-17
Toast detailed order extraction guide ↗
Modified-date extraction versus businessDate; pageSize up to 100 and Link pagination · Checked 2026-10-17
Replay and gap recovery 5.0/10
Bounded redelivery or overlapping queries; no durable consumer checkpoint
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Consumers can repeat bounded modification-time ranges, deduplicate by provider identity and overlap recent ranges to reconcile retries. The documented business-date traversal also rebuilds available current order records. No retained event log, unlimited lookback or deleted-payload restoration is established.
Toast detailed order extraction guide ↗
Modified-date extraction versus businessDate; pageSize up to 100 and Link pagination · Checked 2026-10-17
Toast retrieve multiple orders ↗
GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fields · Checked 2026-10-17
Toast API rate limiting ↗
Global and per-API limits; ordersBulk limits; historical extraction; X-Toast-RateLimit headers and Retry-After · Checked 2026-10-17
Data exit
20% of the overall score before applicability adjustment.
Scored answers and evidence
Export custody 7.5/10
Customer-held structured files or API records
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Toast documents retrieving order records for storage in an integration data warehouse. Customers can hold those structured records outside Toast; this establishes custody of the assessed records, not a provider-delivered database or every POS attachment and setting.
Toast data warehouse reporting recipe ↗
Retrieve previous business-day orders; reporting storage; restaurant closeout-hour handling · Checked 2026-10-17
Post-cancellation access Disclosure
-
Disclosure only; does not reduce planned-exit credit.
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
The API agreement describes termination of API permission and deletion duties, with legal-retention exceptions. It does not establish a merchant subscription cancellation retrieval window or an entitlement to continued order API access after cancellation.
Toast API Terms of Use ↗
Updated June 23, 2026; sections 2.1, 4.2-4.3, 5, 11.1-11.2 and 11.6 · Checked 2026-10-17
Planned migration fidelity 7.5/10
Portable structured records on documented routes; whole-product completeness unverified
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Order payloads preserve provider GUIDs, nested check and selection records, monetary fields and permitted payment references for migration. Guest fields vary by channel and scope. This does not establish export of native workflows, payment credentials, every document or all historical versions.
Toast retrieve multiple orders ↗
GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fields · Checked 2026-10-17
Toast Standard API frequently asked questions ↗
GET-only access; guest information limitations for in-store versus takeout/delivery orders · Checked 2026-10-17
Business logic and customization
5% of the overall score before applicability adjustment.
Scored answers and evidence
Logic authoring 2.5/10
External integration code; native business logic portability not established
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Developers can implement order-reading and approved order-writing integrations using the documented APIs (external code). The assessed documentation does not establish customer export or independent execution of Toast native routing, kitchen or pricing workflow definitions.
Toast custom integration overview ↗
Restaurant development teams and trusted technology partners; request access through Toast representative · Checked 2026-10-17
Toast partner integration development process ↗
Partner application and agreement; certification; production credentials; geography expansion · Checked 2026-10-17
Rights to custom logic -
-
Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim.
Merchant ownership of business data does not establish ownership, reusable export or independent execution rights for native Toast workflow definitions. The reviewed API license does not resolve that separate artifact question.
Toast API Terms of Use ↗
Updated June 23, 2026; sections 2.1, 4.2-4.3, 5, 11.1-11.2 and 11.6 · Checked 2026-10-17
Scores are out of 10. * Incomplete evidence discounts verified capabilities (unknown answers stay unknown). Planned migration drives data exit. Scoring method ↗
CUSTOMER CHOICE
Third-party accessibility
A restaurant can create Standard read credentials and securely share them with its development team. A chosen partner needing production writes follows Toast application, agreement and certification; a bespoke trusted developer requests custom access through a Toast representative. Customer read credentials do not bypass those write gates.
Confirm who can connect, who owns the credentials and which uses are permitted. Customer consent and provider approval can be separate requirements; the selected plan and contract still matter.
READ / INTEGRATE
API and export routes
The Orders API returns structured orders with checks, selections, amounts and payment references for authorized restaurants. Standard access is read-only; guest details depend on order channel and granted scopes. This assessment covers restaurant order records, not every Toast service. Traverse /ordersBulk pages across bounded modified-date or business-date windows to retrieve scoped order records. This is an API extraction into an integration-owned store, not a delivered database replica or a verified complete POS backup. Orders support modified-date ranges or a businessDate filter and paginated results. These are fixed order filters; the documented route does not establish general SQL over Toast.
| Access route | Authentication | Credential owner | Provider approval | Access requirement | Last checked |
|---|---|---|---|---|---|
| Toast approved partner order API | OAuth client credentials | Integration provider | Yes | Partner approval | 2026-10-17 |
| Toast customer Standard read-only API | OAuth client credentials | Customer | No | Customer-supplied credentials | 2026-10-17 |
| Toast bespoke restaurant integration | OAuth client credentials | Customer | Yes | App review | 2026-10-17 |
Availability depends on your product, plan and agreement. See the documentation below for the requirements of each route.
ECONOMIC ACCESS
Cost, authentication and limits
For the Standard read route, every participating location needs an active RMS Essentials or higher subscription, obtained separately from Toast Shop. This establishes a recurring access requirement, without a verified amount. Partner/custom write fees and regional commercial terms remain separate and unresolved.
Check API entitlement, credential ownership and rate limits for the route you intend to use. Include review fees, customer-plan upgrades and ongoing access charges in the total.
ACT FROM OUTSIDE
External action
Approved credentials with appropriate order scopes can POST a new order and POST selections to an existing order check. These are documented order creation and modification operations, with restaurant authorization and provider validation. Standard API credentials cannot write; payment execution and arbitrary order deletion are outside this assessment.
Validate the supported operation, acting identity and permission scope (read access does not imply write permission). Ambiguous retries and revoked credentials also affect whether an external workflow can run safely.
KEEP ACCESS USEFUL
Continuity
The order collection accepts modification-time windows, including new orders, and order webhooks announce new or updated orders. Use authorized REST reads for fields omitted from webhook payloads, including protected guest details. Events are refresh hints rather than proof of retained event replay. Order and check payloads expose deletion flags and dates, while order/selection payloads expose void state. Re-read modified windows and preserve those identities and states. These are soft-delete and void signals for returned orders; permanent purges, intermediate versions and ungranted records are not proved recoverable. Consumers can repeat bounded modification-time ranges, deduplicate by provider identity and overlap recent ranges to reconcile retries. The documented business-date traversal also rebuilds available current order records. No retained event log, unlimited lookback or deleted-payload restoration is established. Default limits are 20 requests/second and 10,000/15 minutes, generally per client and restaurant when the restaurant header is present. ordersBulk additionally allows 5/second; historical windows are at most one month with calls spaced 5-10 seconds. Rate-limit/reset headers and 429 Retry-After support recovery; account-specific exceptions require separate confirmation.
CDC, deletions and recovery
| Question | Answer / applicable route | Evidence |
|---|---|---|
| Can ongoing extraction identify updates and deleted records on the declared route? | Updates and deletion identities documented for the stated resourcesToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Order and check payloads expose deletion flags and dates, while order/selection payloads expose void state. Re-read modified windows and preserve those identities and states. These are soft-delete and void signals for returned orders; permanent purges, intermediate versions and ungranted records are not proved recoverable. | Toast retrieve multiple orders ↗GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fieldsChecked 2026-10-17 Toast detailed order extraction guide ↗Modified-date extraction versus businessDate; pageSize up to 100 and Link paginationChecked 2026-10-17 |
| How can extraction recover after missed events or an interrupted consumer? | Bounded redelivery or overlapping queries; no durable consumer checkpointToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Consumers can repeat bounded modification-time ranges, deduplicate by provider identity and overlap recent ranges to reconcile retries. The documented business-date traversal also rebuilds available current order records. No retained event log, unlimited lookback or deleted-payload restoration is established. | Toast detailed order extraction guide ↗Modified-date extraction versus businessDate; pageSize up to 100 and Link paginationChecked 2026-10-17 Toast retrieve multiple orders ↗GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fieldsChecked 2026-10-17 Toast API rate limiting ↗Global and per-API limits; ordersBulk limits; historical extraction; X-Toast-RateLimit headers and Retry-AfterChecked 2026-10-17 |
Useful ongoing access includes corrections and deletions, not only the first export. A failed request, changed filter or lost resource permission should not be interpreted as a deleted record.
LEAVE WITH YOUR DATA
Data exit and portability
Order payloads preserve provider GUIDs, nested check and selection records, monetary fields and permitted payment references for migration. Guest fields vary by channel and scope. This does not establish export of native workflows, payment credentials, every document or all historical versions. The API agreement describes termination of API permission and deletion duties, with legal-retention exceptions. It does not establish a merchant subscription cancellation retrieval window or an entitlement to continued order API access after cancellation.
Test the output against the destination’s required fields and history. Check stable identifiers, relationships, attachments and extraction time; a sample file proves only the coverage of that sample.
BUILD / INSPECT / REUSE
Business logic and customization
Developers can implement order-reading and approved order-writing integrations using the documented APIs (external code). The assessed documentation does not establish customer export or independent execution of Toast native routing, kitchen or pricing workflow definitions. Merchant ownership of business data does not establish ownership, reusable export or independent execution rights for native Toast workflow definitions. The reviewed API license does not resolve that separate artifact question.
Custom API access, ownership of workflows and the right to export their definitions are separate questions. A custom-app capability alone does not establish that business rules can move to another system.
AGREEMENTS / API DOCS / PROGRAM REQUIREMENTS
Documented conditions
Answers below come from public provider materials. Every answer retains its source check date, scope (a partner agreement does not describe every customer route). Customer contracts and live behavior still need verification.
| Question | Answer / applicable route | Evidence |
|---|---|---|
| What structured read interface is documented? | Structured API for the declared product scopeToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. The Orders API returns structured orders with checks, selections, amounts and payment references for authorized restaurants. Standard access is read-only; guest details depend on order channel and granted scopes. This assessment covers restaurant order records, not every Toast service. | Toast retrieve multiple orders ↗GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fieldsChecked 2026-10-17 Toast Standard API access ↗Standard API access overview; read-only access and location selectionChecked 2026-10-17 Toast Standard API frequently asked questions ↗GET-only access; guest information limitations for in-store versus takeout/delivery ordersChecked 2026-10-17 |
| How can customers retrieve data in bulk? | Batched or iterable API requestsToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Traverse /ordersBulk pages across bounded modified-date or business-date windows to retrieve scoped order records. This is an API extraction into an integration-owned store, not a delivered database replica or a verified complete POS backup. | Toast retrieve multiple orders ↗GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fieldsChecked 2026-10-17 Toast detailed order extraction guide ↗Modified-date extraction versus businessDate; pageSize up to 100 and Link paginationChecked 2026-10-17 |
| What queries can a customer issue outside the provider UI? | Documented structured API filtersToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Orders support modified-date ranges or a businessDate filter and paginated results. These are fixed order filters; the documented route does not establish general SQL over Toast. | Toast retrieve multiple orders ↗GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fieldsChecked 2026-10-17 Toast detailed order extraction guide ↗Modified-date extraction versus businessDate; pageSize up to 100 and Link paginationChecked 2026-10-17 |
| Who decides whether a chosen third party may connect? | Separate provider consent or partner agreement requiredToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. A restaurant can create Standard read credentials and securely share them with its development team. A chosen partner needing production writes follows Toast application, agreement and certification; a bespoke trusted developer requests custom access through a Toast representative. Customer read credentials do not bypass those write gates. | Toast Standard API credentials ↗Create credentials; location and scope grants; secure sharing, rotation and revocationChecked 2026-10-17 Toast partner integration development process ↗Partner application and agreement; certification; production credentials; geography expansionChecked 2026-10-17 Toast custom integration overview ↗Restaurant development teams and trusted technology partners; request access through Toast representativeChecked 2026-10-17 |
| What extra commercial condition applies to the routes supplying the assessed read capability, relative to the lowest paid plan? | Higher plan, separately licensed add-on or fixed recurring access feeToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. For the Standard read route, every participating location needs an active RMS Essentials or higher subscription, obtained separately from Toast Shop. This establishes a recurring access requirement, without a verified amount. Partner/custom write fees and regional commercial terms remain separate and unresolved. | Toast Standard API access requirements ↗Active employee, Manage Integrations permission and RMS Essentials or higher at every locationChecked 2026-10-17 Toast Standard API access ↗Standard API access overview; read-only access and location selectionChecked 2026-10-17 |
| What permission is needed for the documented downstream use? | Published purpose and confidentiality boundariesToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. The API terms recognize merchant ownership of business data and permit merchant-consented AI processing within the integration purpose and onward-disclosure duties. Training or improving models using API-passing data, including synthetic derivatives, requires Toast prior written approval. This finding covers merchant-directed operations and analysis, not unrestricted redistribution or training. | Toast API Terms of Use ↗Updated June 23, 2026; sections 2.1, 4.2-4.3, 5, 11.1-11.2 and 11.6Checked 2026-10-17 |
| Which external write operations are documented? | Create and update in one business domainToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Approved credentials with appropriate order scopes can POST a new order and POST selections to an existing order check. These are documented order creation and modification operations, with restaurant authorization and provider validation. Standard API credentials cannot write; payment execution and arbitrary order deletion are outside this assessment. | Toast create an order ↗POST /orders; restaurant header; persisted Order response and validation errorsChecked 2026-10-17 Toast add items to an order check ↗POST /orders/{orderGuid}/checks/{checkGuid}/selections; add selections to an existing checkChecked 2026-10-17 Toast API scopes ↗Orders API read/write scopes and channel-scoped accessChecked 2026-10-17 Toast Standard API access ↗Standard API access overview; read-only access and location selectionChecked 2026-10-17 |
| How can customers connect an application they build or choose? | Approved third-party applications using fixed interfacesToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Toast supports customer-developed integrations and approved partner applications on fixed APIs. Production partner credentials follow provider certification; custom write access is requested through Toast. The self-service Standard read route does not establish an unreviewed public write application. | Toast partner integration development process ↗Partner application and agreement; certification; production credentials; geography expansionChecked 2026-10-17 Toast custom integration overview ↗Restaurant development teams and trusted technology partners; request access through Toast representativeChecked 2026-10-17 Toast Standard API access ↗Standard API access overview; read-only access and location selectionChecked 2026-10-17 |
| What mechanism supports repeatable extraction of changes? | Documented updated-since filters or webhooksToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. The order collection accepts modification-time windows, including new orders, and order webhooks announce new or updated orders. Use authorized REST reads for fields omitted from webhook payloads, including protected guest details. Events are refresh hints rather than proof of retained event replay. | Toast detailed order extraction guide ↗Modified-date extraction versus businessDate; pageSize up to 100 and Link paginationChecked 2026-10-17 Toast order webhook reference ↗order_updated payload, event identity and omitted guest informationChecked 2026-10-17 Toast Standard API webhook subscriptions ↗Manage Integrations permission; webhook endpoint, secret and event subscription configurationChecked 2026-10-17 |
| How are integration limits disclosed? | Published numeric quotas and recovery instructionsToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Default limits are 20 requests/second and 10,000/15 minutes, generally per client and restaurant when the restaurant header is present. ordersBulk additionally allows 5/second; historical windows are at most one month with calls spaced 5-10 seconds. Rate-limit/reset headers and 429 Retry-After support recovery; account-specific exceptions require separate confirmation. | Toast API rate limiting ↗Global and per-API limits; ordersBulk limits; historical extraction; X-Toast-RateLimit headers and Retry-AfterChecked 2026-10-17 |
| Where can a usable data copy be delivered? | Customer-held structured files or API recordsToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Toast documents retrieving order records for storage in an integration data warehouse. Customers can hold those structured records outside Toast; this establishes custody of the assessed records, not a provider-delivered database or every POS attachment and setting. | Toast data warehouse reporting recipe ↗Retrieve previous business-day orders; reporting storage; restaurant closeout-hour handlingChecked 2026-10-17 |
| What retrieval rights are documented at cancellation? | -Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. The API agreement describes termination of API permission and deletion duties, with legal-retention exceptions. It does not establish a merchant subscription cancellation retrieval window or an entitlement to continued order API access after cancellation. | Toast API Terms of Use ↗Updated June 23, 2026; sections 2.1, 4.2-4.3, 5, 11.1-11.2 and 11.6Checked 2026-10-17 |
| How can customers define their own business logic? | External integration code; native business logic portability not establishedToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Developers can implement order-reading and approved order-writing integrations using the documented APIs (external code). The assessed documentation does not establish customer export or independent execution of Toast native routing, kitchen or pricing workflow definitions. | Toast custom integration overview ↗Restaurant development teams and trusted technology partners; request access through Toast representativeChecked 2026-10-17 Toast partner integration development process ↗Partner application and agreement; certification; production credentials; geography expansionChecked 2026-10-17 |
| What rights or portability are documented for custom workflow artifacts? | -Toast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Merchant ownership of business data does not establish ownership, reusable export or independent execution rights for native Toast workflow definitions. The reviewed API license does not resolve that separate artifact question. | Toast API Terms of Use ↗Updated June 23, 2026; sections 2.1, 4.2-4.3, 5, 11.1-11.2 and 11.6Checked 2026-10-17 |
| What usable data or native definitions can leave before cancellation? | Portable structured records on documented routes; whole-product completeness unverifiedToast restaurant POS: permission-scoped order, check and selection records at US restaurant locations. Standard customer API reads and separately approved partner/custom order writes are assessed as distinct routes; no whole-product, payroll or payment-processing export claim. Order payloads preserve provider GUIDs, nested check and selection records, monetary fields and permitted payment references for migration. Guest fields vary by channel and scope. This does not establish export of native workflows, payment credentials, every document or all historical versions. | Toast retrieve multiple orders ↗GET /ordersBulk; modified-date and business-date filters; page/pageSize; Order and Check deleted/voided fieldsChecked 2026-10-17 Toast Standard API frequently asked questions ↗GET-only access; guest information limitations for in-store versus takeout/delivery ordersChecked 2026-10-17 |
SOURCES / SCOPE / HISTORY
Sources and open questions
This review is based on the documentation below. Live account behavior and customer-specific agreements haven’t been tested.
Still to confirm
- Contractual post-cancellation retrieval terms
- Native workflow artifact ownership, reusable export and independent execution
Documentation
Assessment checked 2026-10-17. Each answer retains its source and applicable route; the check date does not establish live account behavior.