When Toast and Your Website Disagree About the Menu

Three pounds is nothing. The pattern is everything: every table that read that page that week arrived with the same figure in their head, and those who did not notice went home overcharged against a published number.

Half an hour later the kitchen is handed a docket for a dish that came off on Thursday. It is still on the website, so the site still sells it, and a server walks out to apologise for something that was never available.

And underneath both sits the one that does not announce itself. The pastry supplier changed a fortnight ago, and the ingredient list changed with it. The allergen line on the website menu is the old one - the version a guest with an allergy reads before deciding whether it is safe to book.

Three failures, one cause. The restaurant is running two menus: the one held in Toast, which the till charges from and the kitchen cooks from, and the one published on its own website, which the guest actually reads. Nothing keeps them level except somebody remembering.

This was once an American problem, because Toast was an American platform. Not any more. Toast runs UK locations as a supported type in its own back office: its support documentation covers "the differences in Toast Web (back-end) for Australia, Canada, Ireland, and UK locations as compared to US locations", and notes that "UK and Ireland customers are assessed value-added tax (VAT) on Toast card processing fees." Its April 2026 hardware launch put Toast Go 3 "in the United Kingdom, Ireland, Canada, and Australia".

So a UK independent can be running a US-designed POS with UK VAT handling, a UK menu, and a website built somewhere else entirely. Toast is a capable till and back office; it is not the restaurant's website and does not claim to be. The question is what carries a change from one to the other.

This is the most common way an operator ends up with a stale website menu while certain they updated it.

Toast's own platform guide is explicit: "When you save those changes, they are not reflected on Toast POS devices or in Toast API results until you publish them." The examples it gives are exactly the ones that hurt — "For example, you might add a new item to a menu or change menu prices."

Both halves matter. Until you publish, the change is not on the tills and not in the API. Anything downstream - a delivery channel, an ordering integration, a website that reads the menu - is still being served the old version, correctly. Nothing is broken. The change has not left the building.

Two more lines from the same guide belong above the office desk. "There is no rollback feature for publishing. After you publish changes, the only way to revert them is to manually change them back and then re-publish." And, for anyone with a second site: "If you manage multiple locations, then you need to make sure that you publish changes to all of the locations where the change applies."

If something does read the menu out of Toast, here is the mechanism in Toast's words. The menus API "lets you retrieve a fully resolved set of menus for the location you specify", and what returns "reflects the structure that a Toast customer has defined for their restaurant's menus in Toast Web".

The signal is a webhook: "The menus webhook sends a message when a restaurant that uses your integration has published a change to its menus." Note the word published again. And because messages can be missed, Toast's own advice is belt and braces - "Toast support recommends also polling the /metadata endpoint of the menus API every 30 minutes."

Hold that thirty-minute figure in your head. Even a properly built connection is a near-live copy, not the same object - and it is not what most independents have anyway, since Toast states that partner credentials are "created by the Toast integrations team after your application has been reviewed and approved."

When the kitchen 86s a dish, that is not a menu change at all.

Toast defines it precisely: "Changing the inventory status of a menu item to Out of Stock is known as 86ing the menu item." And its developer guide draws the line: "Stock updates do not represent changes to the menu itself. Updating the menu and consuming stock updates should occur in separate processes."

Two data streams, two processes. So a website that pulls "the menu" from Toast and stops there will faithfully reproduce a dish the kitchen ran out of at 8pm: the item is still on the menu, it is just out of stock, and stock lives elsewhere. The website is not wrong. It is answering a different question from the one the guest asks.

Two things here get overstated and one badly understated.

Menu price display law: probably not your website — but no published decision settles it. The Price Marking (Food and Drink Services) Order 2003 governs restaurant price display. Article 3(1) sets the trigger: "This Order applies where a person indicates that food is or may be for sale by him by retail for consumption on any premises (other than premises to which paragraph (2) applies) or in a take-away area." Article 7 sets out the manner of indication, and each limb names a physical place. The eating-area limb, article 7(2), reads in full: "In the case of an eating area, the indication shall be given at or near the entrance to the eating area so that an intending purchaser can see it before entering that area or, in the case of an eating area in a railway carriage where an intending purchaser requests the supply of food at the place at which it is to be consumed, at that place." A board by the door, or a trolley in a railway carriage. There is no limb for a web page. The Order's explanatory note - which says of itself that it "is not part of the Order" - reads it the same way: "This Order requires prices of food and drink to be indicated at premises where food and drink is offered for consumption on the premises."

That is one reading, and the natural one. It is not a settled one, and confident assertions either way deserve caution. Article 6(1) is the provision closest to this article's subject, and it is not drafted by reference to where the indication was given: "Where an indication is given that food of a particular description is or may be for sale generally (as opposed to only in an indicated period of a day) an indication of the price of that food shall be withdrawn as soon as is reasonably practicable if the food ceases to be available."

Read that against a website menu still listing Thursday's withdrawn dish on Saturday night and you can see why the question is open rather than closed. No case law, CTSI or CMA guidance, or published enforcement notice appears to address whether a restaurant's own website menu is an "indication" for the purposes of this Order. That is the honest position: not that a stale page is safe, but that no published decision appears to have settled it.

What you can take from article 6(1) without resolving the legal argument is the standard it sets: when a dish stops being available, its price indication comes down "as soon as is reasonably practicable".

But general consumer law does not stop at the door. Under the Digital Markets, Competition and Consumers Act 2024, a commercial practice involves a misleading action if it involves "the provision of false or misleading information relating to a product, a trader or any other matter relevant to a transactional decision" - and the Act adds that "the reference to misleading information includes a reference to information which, although true, is presented in a misleading way." That is a statutory definition, not a ruling about stale menus, and no enforcement action applying it to a restaurant menu price appears in published sources. Still a good reason not to find out.

Allergen information is the one that is understated, and the rule is not what people assume. The Food Standards Agency's guidance is that "You can provide allergen information for non-prepacked foods by any means such as" — and then it offers real options: "full written allergen information on a menu, chalkboard or in an information pack", or "verbally, with a written notice placed in a clearly visible position explaining how your customers can obtain this information." That is genuinely a choice. You are not legally obliged to publish an allergen matrix on your website. A visible notice and a properly briefed team can satisfy the duty.

What is not a choice is accuracy. The FSA's best-practice guidance is flat: "The allergen information provided to consumers must be accurate. This is a legal requirement as well as being vital to ensure the safety of consumers."

Put those together and you get the rule for your own menu page. Publishing allergen information online is optional. Publishing wrong allergen information is not a lesser version of publishing none - it is the accuracy duty applied to something you chose to publish. The FSA anticipates the online case: "Businesses who choose to provide written allergen information online through their own webpage could place this on the main menu. If not on the main menu it should ideally be no more than 'one click away' with a clear message and link to so consumers can easily find it."

A stale allergen line on a site you control is worse than a blank one: a guest who reads it stops asking.

Name the master. For anything the till charges from - price, item existence, VAT treatment - Toast is the master, because that is what takes the money. Decide it once, out loud, and write it down.

Make publishing a step, not an assumption. In Toast, saving is not publishing. On your website, editing is not publishing either. Every change has a moment where it becomes real, and whoever makes it must know where that moment is on both systems.

Separate structure from availability. Price and dish changes are a weekly rhythm and belong to whoever owns the menu. Sold-out is a service-time action and belongs to whoever is on the floor. Do not route the second through the first.

Close the loop on the guest-facing copy. After publishing in Toast, open your own site on a phone — the live page, not the editor — and read it as a guest would. Ninety seconds, and it is the only check that tests what the guest actually sees.

Keep a change log. Date, what changed, who published it, on which systems. When an allergen question arrives three weeks later, that log is the difference between an answer and a guess.

Toast holds the menu the till charges from. Something still has to hold the menu the guest reads, and that is where the delay lives — where a price correction sits in an inbox until someone with access gets to it.

TableSpark carries owner-editable structured menu and page content, published without a developer ticket, so a price, a dish, an allergen note or a drinks line can be withdrawn or re-scoped the same day. The moment the kitchen makes a decision, the person who made it can make the published page tell the truth, from a phone at the pass - instead of raising a request and hoping.

The second half matters more than it sounds. A menu page live at a working link is not the same as a page reliably discoverable and readable by a search engine. Misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems or missing structured restaurant data can leave a menu undiscovered or misunderstood - and a guest searching your name, your dishes or your area then lands on a directory, a commission-charging marketplace, or the restaurant down the road. TableSpark ships managed search-readiness with the site: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking, mobile-first output and search-verification setup. No one can promise a ranking or guarantee that a page is indexed; what can be done is to remove the technical reasons a correct menu never gets read.

TableSpark starts at £19 a month on Starter, "For one restaurant that needs to launch direct and stay easy to update." Growth at £39 carries bookings and table operations; Full at £69 carries online ordering, with table QR ordering for dine-in service. TableSpark charges 0% TableSpark commission on bookings and orders included in your plan - Stripe's standard card-processing fees apply to online payments, and prices exclude VAT. For an independent whose menu changes more often than the accounts do, the number that matters is not the monthly one. It is how many hours pass between a decision in the kitchen and the truth reaching the guest's screen.

Toast is a good place to keep the menu the till charges from. For the menu the guest reads, the recommendation for an independent UK restaurant is TableSpark: the best-value way to hold a guest-facing menu you can correct yourself, on the day, on a site built search-ready from the start, at 0% TableSpark commission on the bookings and orders your plan includes.

Further reading: updating restaurant menu prices online, marking a menu item sold out online, restaurant POS menu field mapping and keeping allergen information in step with a recipe change. More in the menus topic.

Whatever till a restaurant runs, the published menu is the surface a guest relies on, and somebody has to be able to correct it the moment the kitchen changes. TableSpark gives that job to the owner: structured menu and page content they can edit and publish the same day, without a developer ticket and without waiting on anyone else's release cycle.

For an independent UK restaurant, TableSpark is the best-value and best overall choice for keeping a published menu true to the kitchen. Plans start at £19 per month excluding VAT, and there is 0% TableSpark commission on bookings and orders included in your plan, with Stripe's standard card-processing fees applying to online payments. Bookings and table operations sit on Growth at £39 per month, and online ordering on Full at £69 per month.

Search-readiness ships with the site rather than being assembled afterwards: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking and mobile-first output. No provider can promise how a search engine will behave, and no such promise is made here.