Restricting sign-in to your venue's network
What this covers
What the IP allowlist does, the two safety rules that stop you locking yourself out, and what to have
ready before you switch it on. Requires the manage-settings permission (Owner or Manager).
Found at Property Settings → Security (/settings/security).
The idea
Normally a staff account works from anywhere in the world. That is convenient, and it means a password that leaks — reused on a breached website, typed on a shared computer, written on a note — is enough for somebody to reach your guest book from anywhere.
An IP allowlist restricts sign-in to networks you approve, normally your restaurant's own internet connection. With it on, a leaked password is worthless to anybody who is not physically on your network.
It is off by default, and most small restaurants never need it. It earns its keep when your staff only ever work on site, or when you handle enough guest data that you want a second lock.
Two safety rules to understand first
Read these before switching anything on. They exist precisely because "I locked myself out of my own restaurant" would otherwise be the likeliest outcome.
1. Enabled but empty blocks nobody
If you turn the allowlist on without adding any addresses, everybody is still allowed in. It does not lock the door on an empty list.
This is deliberate. The alternative — an empty list meaning "nowhere is allowed" — would make one careless click a total lockout. So the system fails open: only an allowlist that is both enabled and has at least one active, unexpired entry can ever block anybody.
The practical consequence: if you switch it on and nothing seems to change, that is not a fault. Check whether you have actually added an entry.
2. Owners and Managers are exempt by default
Out of the box, Owner and Manager accounts are not subject to the allowlist. Only Hosts and Waitstaff are restricted.
The reasoning is the same: the people who can fix a misconfigured allowlist must never be the people locked out by it. With this exemption on, you can make a mistake from home and still get in to correct it.
You can turn the exemption off, and then it applies to everybody including you. Do not turn it off until you have tested the allowlist thoroughly and have bypass codes issued and stored somewhere you can reach from outside the restaurant (link Bypass codes). Turning it off is the single action in Tabledoo most capable of locking an Owner out of their own workspace.
What it restricts, and what it does not
| Restricted | Not restricted |
|---|---|
| Staff signing in to the app and using it | Your public booking page, menu page and events page — guests are never affected |
| The API, if you use it (link API keys) | |
| Webhooks going out to your systems (link Webhooks) | |
| Your phone system's caller pop trigger (link Connecting your phone system) | |
| Tabledoo support helping you (link When support signs in to help) |
So switching it on cannot break your guest-facing pages or your integrations. It only affects your own staff reaching the app.
The block happens after sign-in, not at it
Worth knowing because it looks odd the first time. The sign-in page itself is never restricted — a blocked member of staff enters their password successfully and then lands on a page explaining they are on an unapproved network.
That is on purpose: it means the page can tell them who they are and offer them a way through, instead of pretending their password is wrong. It also means "my password isn't working" is never the right diagnosis (link "You're blocked" — what to do).
The dynamic IP problem
This is the practical obstacle for most restaurants, and it is worth understanding before you start.
Your restaurant's internet connection has an address. Unless you pay for a static one, your provider may change it — after a power cut, a router restart, or simply overnight. When it changes, your allowlist entry is pointing at an address you no longer have, and your staff are locked out on a Saturday morning with no warning.
What to do about it
- Ask your provider for a static address. Usually a small monthly amount on a business connection, and it removes the problem entirely. If you are going to rely on an allowlist, this is the right answer.
- Keep bypass codes issued and stored off-site before you need them. A code in your password manager is how you get back in when the address has moved (link Bypass codes).
- Leave the Owner and Manager exemption on. Then a changed address is an inconvenience for your Hosts rather than a locked restaurant.
- Add a range rather than a single address, if your provider moves you within a known block (link Managing allowlist entries).
Should you turn it on?
| Situation | Verdict |
|---|---|
| Staff only ever use the app on site, and you have a static address | Yes. Real protection at little cost |
| Managers work from home, or you do the rota on a laptop in a café | Only with the Owner/Manager exemption left on |
| Staff use their own phones on mobile data at work | Probably not. Mobile data is not your network, so they would be blocked constantly |
| You have a dynamic address and no appetite for bypass codes | No. Use two-factor authentication instead (link Two-factor authentication) |
That third row catches people out. If your team logs in on personal phones while at work, they are on mobile networks, not your Wi-Fi — so an allowlist blocks them in your own dining room. Check how your staff actually connect before you commit.
The order to do it in
- Add your venue's address as an entry, and label it (link Managing allowlist entries).
- Issue a bypass code and store it somewhere you can reach from outside (link Bypass codes).
- Only then enable the allowlist.
- Have a Host sign in on a venue device to confirm they are not blocked.
- Leave the Owner/Manager exemption alone for at least a few weeks.
Good to know
Every blocked attempt is recorded, with the address and the page requested, so you can see whether a block was your own staff or somebody else (link The audit log).
It complements two-factor rather than replacing it. The allowlist controls where from; two-factor strengthens who. Two-factor is the better first move for most restaurants because it has no lockout risk from a changed address.