Toast Website Integration: What to Know Before You Build

Toast website integration usually fits one of three patterns: a direct link from the marketing site to Toast-hosted ordering, an embedded Toast widget on a dedicated /order page, or a fully custom UI that calls Toast’s API. The right pattern depends on brand needs, page-speed budget, and multi-location structure.

Toast is the most-used POS we wire restaurant sites to at the studio. The integration question gets asked at almost every kickoff, usually phrased as “can we just keep our Toast ordering and have you build the rest?” The answer is yes, and the shape of that yes is the entire conversation.

The wrong pattern shows up later as page-speed regressions on the homepage, broken menu routing between locations, or a mobile checkout flow that nobody on the team is sure how to fix. Most of those problems are decisions, not bugs — choices made in week one that nobody revisited before launch. This post is the walk-through we run with operators before any code gets written.

The three integration patterns

Three patterns cover almost every Toast website integration we ship. Each has a different cost, a different brand feel, and a different page-speed profile. Picking one early — and writing it down — is the difference between a clean launch and a six-week tail of cleanup tickets.

Pattern 1: Direct link to Toast-hosted ordering

The marketing site has an “Order Online” button. The button points to a Toast-hosted ordering URL. Guests click, the browser opens the Toast-hosted ordering flow, the order completes on Toast’s domain.

Pros: zero performance cost on the marketing site, no third-party JS in the page, no embed to maintain. Toast handles everything past the click. Implementation is a single anchor tag and a UTM parameter for analytics.

Cons: the brand handoff happens at click time. Once the guest leaves the marketing site, the experience is Toast’s defaults — Toast’s fonts, Toast’s spacing, Toast’s checkout. For operators with a strong brand, that handoff can feel jarring.

Right for: single-location operators who care more about speed and simplicity than brand continuity inside the ordering flow. Also the right pattern for operators who don’t have a designer ready to wrestle the embed into the brand system.

Pattern 2: Embedded Toast widget on /order page

The marketing site has a dedicated /order page. The Toast ordering widget is embedded on that page via the script tag and container div Toast provides. The brand header, footer, and nav stay wrapped around the widget so the guest never sees a Toast-branded page.

Pros: brand continuity. The guest feels they ordered from the restaurant, not from Toast. Analytics stay first-party. Page-level meta and schema stay under the site’s control.

Cons: the Toast widget is heavy third-party JavaScript. Done badly, it tanks the page’s LCP score and bleeds into the rest of the site’s performance budget. Mobile rendering of the widget is good but not pixel-perfect against custom brand systems.

Right for: operators who want guests to feel they never left the brand and who have a /order page dedicated to the flow (not the homepage, not the menu page).

Pattern 3: Custom UI calling Toast’s API

The website renders the entire ordering UI in custom code. Menu items, modifiers, cart, checkout, payment — all built in the site’s framework, calling Toast’s API on the backend for menu data and order submission.

Pros: total brand and UX control. Animations, micro-interactions, copy, and accessibility all match the rest of the site exactly. Performance can be tuned to the byte.

Cons: full development cost and full ongoing maintenance burden. Toast’s API surface changes, and your team owns every change. Compliance with PCI and Toast’s order-submission requirements becomes your problem.

Right for: enterprise operators with internal engineering resources, or brands where the ordering UX is itself a brand differentiator. For most independents and small chains, this is over-scoped.

Four gotchas every Toast integration runs into

Even with the pattern picked, four issues show up over and over. Plan for them before launch, not after.

Page-speed cost of the embedded widget

The Toast ordering widget is third-party JavaScript, and like all third-party JS it costs LCP, TBT, and CLS budget. Embedding it on the homepage or the menu page — both of which are top-of-funnel high-traffic pages — punishes the most important pages on the site. The fix is to keep the widget on /order only, lazy-load it on user interaction where possible, and never let it run on routes guests visit before they’ve decided to order.

Multi-location routing

Toast supports per-location ordering URLs, but the logic that picks the right URL has to live on the website side. The location-selection UI, the cookie that remembers the last chosen location, the routing rule that sends a Sawtelle guest to the Sawtelle ordering URL — all of that is the site’s job, not Toast’s. Operators who skip the routing step end up with one default location that swallows orders meant for other units. See our multi-location restaurant website structure write-up for the broader pattern.

Menu drift between CMS and Toast

The marketing menu in the website CMS and the live menu inside Toast can drift. A new dish gets added to Toast for ordering but never makes it into the CMS marketing menu, or vice versa. Decide which menu is the source of truth before launch — usually Toast for items and prices, CMS for descriptions and photography — and document the update workflow so the team isn’t guessing six months in.

Accessibility of the embedded widget

Third-party widgets often have keyboard-navigation and focus-management issues that don’t surface until an actual screen-reader user tries to order. Test the Toast widget against the same WCAG baseline you’d hold the rest of the site to, and document the gaps before launch. The full accessibility baseline we ship against is in our restaurant website accessibility WCAG baseline post.

Questions to settle before code starts

Six questions, in this order, before anyone writes a line of integration code:

1. Single-location or multi-location? (Determines whether routing logic is needed.)
2. Brand continuity inside the ordering flow — required or nice-to-have? (Determines Pattern 1 vs Pattern 2.)
3. Page-speed budget on the /order page — what’s the LCP target? (Determines how aggressive the lazy-load needs to be.)
4. Who owns menu updates — the Toast team or the CMS team? (Determines the source-of-truth and the workflow.)
5. Mobile-app strategy — Toast-hosted, custom PWA, or none? (Affects whether the website’s order flow needs to feel app-like.)
6. Loyalty and gift cards — surfaced on the marketing site or only inside Toast? (Determines whether extra Toast modules need their own page integrations.)

Settle these in week one. Each answer narrows the integration shape and removes a class of late-stage rework.

What the integration should not be doing

Three anti-patterns we’ve cleaned up on rebuilds:

Embedding the Toast widget in the homepage hero. The homepage is the highest-traffic, most-shared page on the site. Loading a third-party ordering widget at the top of it slows the page for every visitor — including the ones who are reading the About section, looking at locations, or finding the menu. Keep the widget on /order.

Letting the Toast widget set page meta or schema. The widget doesn’t try to, but operators sometimes assume it handles the SEO around the ordering page. It doesn’t. The /order page’s title, description, canonical, and schema are the site’s job, the same as any other page.

Replacing the site’s menu page with the Toast widget. A menu page built as a real HTML menu — with item names, descriptions, prices, and structured data — is one of the strongest SEO assets a restaurant site has. Swapping it out for the Toast widget makes the menu invisible to search engines, since the widget renders client-side and item content isn’t crawled the same way. The full reasoning is in why your restaurant’s menu shouldn’t be a PDF — the principle applies to widget-only menus too. Keep a real menu page; let the Toast widget live on /order.

Wrapping up

Every Built by Pine engagement that involves Toast starts with the three-pattern decision in week one. The pattern determines page-speed budget, multi-location routing, accessibility scope, and the menu workflow the team will run for years after launch. Pick the pattern, settle the six questions, and the integration becomes a small slice of the build instead of a recurring problem.

If a Toast integration is on the table for an upcoming build, we walk operators through this end-to-end on our restaurant website design projects. And for the related decision of what anchors the homepage — ordering or reservations — see online ordering vs reservations on the homepage.