By Supaorder Team — who we are
Two-Way POS Sync: Clover, Square, Toast
What syncs in each direction between Supaorder and your till, the four switches that control it, and what to have ready before you connect.
“Two-way sync” is a phrase that means different things on different vendors’ pages, so here is exactly what it means on ours: Clover, Toast and Square are supported, and the connection is not one setting but four independent switches, each of which you should turn on deliberately.
This post is what each switch does, what to have ready before you start, and which step is responsible for most of the support tickets.
First, a distinction worth making
Connecting Clover, Toast or Square links you to a third-party till you already own. Supaorder also ships its own POS register as part of the plan, which needs no integration because it is already part of the platform.
They solve the same problem from opposite directions. If you have a till you are happy with, integrate it. If you are replacing one, or opening a site without one, you already have a register. Neither path is the upgrade path for the other, and you should not connect a POS you were planning to retire.
The four switches
| Switch | Direction | What it does |
|---|---|---|
| Sync app orders to POS | Outbound | Online orders appear on your till |
| Sync POS orders to app | Inbound | Counter orders appear in your reporting |
| Push status updates to POS | Outbound | Status changes here are reflected there |
| Terminal states only | Outbound | Push only the final states rather than every step |
They are independent, and that is the point. The commonest setup is not “everything on” — it is outbound orders plus status updates, with inbound added later once the mapping is trusted.
Outbound is the one that changes daily life. Online orders land on the till your staff already use, in the flow they already know, without anybody re-keying anything. Re-keying is where wrong orders come from, so this is an accuracy change as much as a speed one.
Inbound is the one that changes your reporting. Counter orders flow into the same place as online orders, so your sales figures describe the whole restaurant rather than the online slice of it. It is genuinely valuable and it is also the switch to be careful with, because inbound orders go straight into your reporting — and a wrong default distorts it quietly, which is the worst way for a number to be wrong.
Terminal states only exists because not every till wants the play-by-play. If your POS only cares whether an order completed or was cancelled, sending it every intermediate step is noise.
Menu import is a separate thing
Rather than rebuilding your menu, you can preview what the POS holds, import it, and later push changes back. It is configured separately from the sync switches and points at the outlet whose menu is the source.
Preview first, always. POS menus are reliably messier than their owners remember — retired items, test entries, options nobody has used in years — and preview shows you what would come across before it does. The pattern that works: import into one outlet, tidy it there, then use that outlet as the source for the rest.
What to have ready, by vendor
Each provider issues credentials differently, and one of them has a lead time you should know about now rather than in week three.
Clover — Merchant ID (visible in your dashboard), plus App ID and App Secret from an app you create in the developer dashboard, plus a webhook secret generated when you register the callback. The trap: Clover’s app must be installed on the merchant account before the credentials work. A perfectly correct set of credentials on an uninstalled app fails in a way that looks exactly like a typo, and people spend an afternoon retyping them.
Toast — Restaurant GUID, Client ID and Client Secret, a webhook secret, and dining option GUIDs. Two things to plan around. Toast credentials are issued through their partner process rather than self-served, so start earlier than you think you need to — this is the long pole in a Toast project. And Toast identifies delivery, pickup and dine-in by GUID rather than by name, so each of yours has to be mapped. Skipping that mapping does not stop orders syncing; it makes them arrive as the wrong type, which is worse than not syncing at all.
Square — application credentials from an app you create, a webhook signature key, and the production flag set correctly. Square runs separate sandbox and production environments and credentials from one never work against the other. Square also requires the webhook notification URL to be registered against the same application whose credentials you are using; mixing one app’s credentials with another app’s webhook is a silent failure.
Worth repeating, because it comes up: Square here is a POS integration, not a payment gateway. Payments settle through your own gateway account either way.
The webhook step is the one that fails silently
Registering the webhook in the provider’s dashboard and pasting its signing secret back is step three of five, it takes two minutes, and it is the single most common POS support case. Without it, orders and status changes simply never arrive — and nothing errors, because from our side there is nothing to error about. It looks like the integration is connected and asleep.
Leave “verify signature” on. It is what makes the callbacks trustworthy, and turning it off to make something work is trading a real guarantee for a symptom.
A sensible order of operations
- Get the credentials. On Toast, do this first and in parallel with everything else.
- Create the integration and enter them.
- Register the webhook and paste the signing secret back. Verify signature stays on.
- Set the sync switches — outbound only to begin with — and the inbound defaults if you plan to use inbound. Inbound needs a default business type and a default outlet, which is where a counter order lands when the till does not say. Set both or inbound orders have nowhere to go.
- Scope it with conditions if the integration applies to some outlets and not others.
- Test the connection, then place one real order each way and watch it arrive.
Step six is not optional. A connection test proves the credentials work; a real order proves the mapping does.
When sync breaks
A POS that keeps failing is skipped automatically rather than retried into the ground, so a broken till cannot slow your ordering down. Once the cause is fixed, that is reset from the dashboard. There is also an operations view listing sync attempts with a retry action for individual ones — the right tool when a handful of orders failed rather than the connection itself.
The three symptoms worth recognising: nothing syncing either way usually means the connection is skipped and needs resetting after a fix; orders arriving but statuses not moving is the separate status switch; and “it worked and then stopped” is almost always a rotated credential or webhook secret that was not updated here.
The full setup reference, including the troubleshooting table, is in the documentation. POS sync is part of the plan rather than a per-location add-on — and if you are already rebuilding your ordering because GloriaFood closes on 31 March 2027, wiring the till in during the rebuild saves doing the menu twice.