Skip to content
Back to BiteTheMenu Site

Keeping your venues' data separate

Your venues share a brand, a menu and a recipe library. What they don’t share is daily operations: orders, stock counts, the roster, sales, tax invoices, customer history.

The rule

A signed-in person can only see and change data for the venues they’re actually attached to — not the venue the request claims to be about.

How it’s enforced

Three things happen on every single action:

  1. Who is asking. Your identity is read from the proof your browser carries, which can’t be forged or passed to someone else.
  2. What they can touch. Your list of attached venues is looked up in the database. The request doesn’t get to declare it.
  3. Does this venue match. The venue in the request is checked against that list. If it isn’t there, the request is refused.

The third check is the load-bearing one, and it runs server-side on every endpoint. The browser can’t override it — not with a modified request, not with developer tools open, not with a hand-written call to the back end.

What that means day to day

The head chef at one location opens orders and sees that location’s tickets. The manager at the other changes a price and it applies there only. The switcher at the top moves you between venues you’re actually attached to — and nowhere else.

What it doesn’t protect against

  • Someone you deliberately attached to both venues. Access is a decision you make, and the system enforces the decision rather than second-guessing it.
  • A shared login. Two people using one account are one person as far as any system is concerned. Give everyone their own.
  • Group-level roles. Someone with a group role reaches the shared catalogues by design — see who can see your group.