POS & integrations
Connect your POS
A step-by-step guide to connecting Square, Toast, Squirrel, MICROS Simphony, or Lightspeed to a venue, including the per-venue webhook secret.
Updated Jul 23, 2026
This guide walks through connecting an external point-of-sale to a venue so it can drive your meal and course status. If you're not sure whether you want this, read How POS integration works first — the built-in POS-lite needs no setup at all.
Before you start
A few things are true for every provider:
- Connections are per venue. Each venue picks its own POS and has its own credentials and webhook secret. Setting one venue up does not touch the others.
- You'll need a webhook secret. This is a shared password TableStack uses to verify that inbound messages really came from your POS. Every venue must have one, or its webhook stays closed.
- Inbound works without outbound. Every connector can receive status from the POS. Only some can also send (open a ticket when a party is seated), and that part needs extra credentials.
Supported providers
| Provider | Drives status inbound | Opens a ticket when seated |
|---|---|---|
| Square | Yes | Yes (with token + location) |
| Toast | Yes | Yes (with token + restaurant id) |
| Lightspeed | Yes | Yes (with token + API base) |
| Squirrel | Yes (via site middleware) | No |
| Oracle MICROS Simphony | Yes | No |
What each venue configures
The connection settings live on the venue. In broad terms you'll set:
- Driver — which POS this venue uses (Square, Toast, Squirrel, MICROS Simphony, or Lightspeed).
- Webhook secret — the shared secret that signs inbound messages. Generate a strong random value and paste the same value into your POS's webhook configuration.
- Access token (for outbound) — the API credential TableStack uses to open a ticket on the POS when a party is seated.
- Provider-specific ids (for outbound) — Square needs a location id, Toast needs a restaurant id, and Lightspeed needs the API base URL for your region.
If you provide only the webhook secret, the venue runs inbound-only: the POS drives status into TableStack, but TableStack won't try to open tickets back on the POS. That's a perfectly valid setup.
How the POS references a TableStack party
Each connector expects your visit's id to travel on the POS ticket — in Square's reference_id, Toast's externalId, Lightspeed's external reference, or the check reference for Squirrel and MICROS. This is set when the ticket is opened (automatically, if outbound is configured). It's how a "check closed" message finds the right party.
A note on Squirrel and MICROS
Squirrel integrations run through on-site middleware rather than a public webhook API, so your integrator posts TableStack the agreed message shape (check.closed, check.course_fired) at the venue's webhook. MICROS Simphony works similarly from its Transaction Services events. Both are inbound-only.
Choose a conflict policy
Decide who wins when both the POS and your staff touch a course or payment state:
- POS is authoritative (recommended) — the POS controls course and payment; staff taps on those states are refused. Staff always keep seating and clearing tables.
- Advisory — staff can still advance manually, but the POS may overwrite them.
Verify it works
- Check the signature path. Send a test event from your POS's sandbox. A correctly signed message is accepted; a wrong or missing signature is rejected.
- Run the certification checklist. This confirms the driver resolves, the secret is set, the inbound mapping is sane, and (if configured) the outbound base is reachable. See Certifying a POS integration.
- Do a live sandbox cycle. Seat a test party, fire a course, and close the check — then confirm the party advanced and shows a total in TableStack.
What this affects
Once connected, the POS drives the service lifecycle and changes what staff can tap on the kitchen display. See How POS integration works for the full ripple.