By Supaorder Team — who we are
Restaurant POS Integration, Explained
What POS integration actually means, why the word covers four different things, what one-way and two-way sync each give you, and where they break.
Restaurant POS integration is a connection between your online ordering system and the till you already run the restaurant on, so that an order placed on the web arrives in the same place as an order taken at the counter — without a person reading it off a tablet and typing it in again.
That is the whole idea. The difficulty is that “integrates with your POS” is used for four arrangements that differ enormously in what they actually save you, and vendors rarely say which one they mean.
Four things called “integration”
A printer or tablet in the kitchen. The order arrives on its own device. Nothing reaches the till. This is not integration, but it is frequently sold beside the word, and for a small site it is sometimes genuinely enough.
One-way: orders into the POS. Online orders are injected as tickets. The re-typing stops, which is most of the value. Your menu still lives in two places and you maintain both.
Menu sync out of the POS. Items, prices and modifiers flow from the till to the ordering system, so the till is the single source of truth. This is the half that stops the price on your site drifting away from the price at the counter.
Two-way: both, plus state. Orders in, menu out, and status flowing back — accepted, ready, sold out. This is what “two-way” should mean and often does not.
When you ask “do you integrate with Square”, the honest answer is one of these four, and it is worth making a vendor pick.
What actually syncs, and what only claims to
Four things can move between the two systems, and they are not equally reliable anywhere.
Orders are the easy one. Every integration worth the name does this, and it is the part that pays for the work.
Menu items and prices are harder than they look, because the two systems disagree about what a menu is. A modifier group on a till is not always a modifier group in an ordering system; a combo, a half-and-half pizza and a weight-priced item each expose the mismatch. Ask to see your own awkward item, not a demo menu.
Stock and 86’d items are where claims get loose. A kitchen marking something unavailable on the till should remove it from the website within seconds, and on several platforms that path either does not exist or runs on a slow poll. This is worth testing before you rely on it on a Friday.
Order status — accepted, being made, ready — is the one most often absent. Without it your customer-facing “your order is ready” is a guess, however good the rest of the connection is.
Why two-way is harder than one-way
One-way is a delivery problem: get a ticket in. Two-way is a conflict problem, and conflicts need rules rather than plumbing.
If a price changes on the till while a basket is open on the web, which one wins? If an item is edited in both places between syncs, which edit survives? If the connection drops for ten minutes during service, does the queue replay in order, and does it replay a cancellation that has since been reversed?
Vendors who have built this have answers, and the answers are specific. Vendors who have not will describe the happy path with enthusiasm. The distinguishing question is not “do you sync” but “what happens when both sides changed”.
What to ask a vendor
Five questions that separate a real connection from a logo on a page:
- Which of the four arrangements above is this? Make them name it rather than say “full integration”.
- Show me my own menu synced, including the item I know is awkward. Combos, weight-priced items, half-and-half, modifier groups with their own modifiers.
- What is the delay on an 86, end to end? Then ask what happens if the connection is down when the kitchen marks it.
- When both sides changed, which wins, and where is that written down? A vendor who has thought about it will answer immediately.
- What do I have to do when the POS vendor changes their API? The honest answer involves them, not you — but it is worth hearing them say it.
When you do not need it
POS integration is a labour-saving device, and the saving scales with how much labour there is to save.
If your online volume is a handful of orders a day and one person handles them between other jobs, a tablet is genuinely fine and the integration will not repay the setup. If your menu almost never changes, menu sync solves a problem you do not have. And if your till is old enough to lack a usable API, the honest answer may be that this waits for the next till rather than becoming a project now.
The place it earns its keep is a busy service with a menu that moves: that is where re-typing turns into wrong orders, and where a price on the website that nobody remembered to update becomes an argument at the counter.
For the decision rather than the definition — whether it is worth it for your operation, and what it changes on a shift — see Restaurant POS Integration: Is It Worth It?. For the mechanics of the sync switches and what each vendor makes you gather, the POS integration page sets them out, and Two-Way POS Sync: Clover, Square, Toast covers how the three differ in practice.