Skip to content
Tablekeep.

Privacy

Last updated 29 September 2026

Tablekeep is a restaurant booking system made and run in Adelaide, Australia. This page explains, plainly, what information we handle and why. Questions or requests, any time: [email protected].

If you enquire on this site

The enquiry and demo forms collect what you type: your name, venue, email, and if you share them, your website, how you take bookings today, rough covers and a message. We use that to reply to you and tailor what we send. We never sell it, never share it with anyone else, and you can ask us to delete it whenever you like.

If we contact your venue first

We keep a list of restaurants we think Tablekeep could suit, built from public sources: the venue's Google listing, its own website and social pages. It holds the venue's name, address, phone, website and a public contact email, plus our own notes on whether we have been in touch. If we send you a demo, it is set up under your venue's public name and details so you can see the product as yours. The demo link expires after 14 days, and we delete the demo venue after that, or whenever you ask. Tell us you would rather not hear from us and we mark your venue do-not-contact; that flag is permanent.

If you book a table at a restaurant that uses Tablekeep

Your booking details (name, contact, party size, occasion, dietary needs and any notes, plus any extra question the restaurant adds to its form) belong to the restaurant you booked with. We store and process them on that restaurant's behalf so your booking works: confirmations, reminders, and changes you make yourself. We record whether those emails were delivered and opened, so the restaurant can tell if a confirmation reached you. If the restaurant turns it on, we send you one message after your visit asking for a review or feedback; every such message has a one-click opt-out, and we never send it more than once every 45 days. We do not use diner details for our own marketing, and we never sell them. For anything about your data at a particular restaurant, that restaurant is the right first contact; we help them honour any request.

We do not build profiles of you across unrelated restaurants. There is one exception, and it is worth being clear about: when several venues run on Tablekeep as one group, either because one business runs them all or because each venue's owner has agreed to join, staff of those venues can see your visit history across the group, matched on your phone number. What they see is your name, contact details, and how many times you visited or did not show up at each venue in the group; your notes, dietary needs and spending stay with the venue that recorded them. It never reaches a venue outside that group. If you would rather your details were not shared this way, ask any venue in the group, or us, to delete them, and we will help.

If you work at a restaurant that uses Tablekeep

We hold your name, email, role and, if your venue uses one, the lock-screen PIN you choose (stored hashed, never readable by us). To keep the app working across your venue's devices we record each device you sign in on: its browser and screen size, whether the app is installed, the app version and when it was last used. Your venue can see this list in its settings; we delete a device record 180 days after it was last used. If you turn on alerts, we store the browser notification subscription that delivers them. We email venue owners occasional set-up tips; every one has a one-click unsubscribe.

Where data lives, and who helps us run it

Our database and login system run with Supabase in Sydney, so booking data is stored in Australia. Like most modern software, we also rely on a small set of specialist providers to do specific jobs, and some of them process data overseas. Each one receives only what it needs for its job, and nothing is ever sold or shared for advertising:

  • Supabase (Sydney, Australia): the database and logins. Booking data stays here.
  • Postmark (United States): delivers booking emails. Receives the email address and the message it is sending, and tells us whether it was delivered and opened.
  • ClickSend (Australia): delivers booking text messages. Receives the phone number and the message. We do not receive replies, so a reply to a text is not read; use the opt-out link in the message instead.
  • Stripe (United States): processes deposits and payments. Card details go to Stripe directly and never touch our systems; Stripe's payment form loads in your browser when a deposit is needed.
  • Cloudflare (global network): serves our pages and the booking widget, and runs the bot check the widget uses before accepting a booking, which sees your connection address.
  • Google (United States): the Places service, which we use to find a restaurant's listing at set-up and to check the public details of venues on our contact list. Never diner booking data.
  • PostHog (United States): usage analytics on this marketing site only, as described below. Never diner booking data.
  • Sentry (United States): tells us when something breaks in the app or the booking widget. Receives technical error details, not booking records.
  • Slack (United States): our internal alerts. Receives a venue's name when something needs our attention, such as a failed import or a new subscription, never diner details.
  • Anthropic (United States): powers the AI helper on plans that include it, plus the set-up assistant and the floor-plan importer, which send only the venue's own set-up details or the image being imported. When staff ask the AI helper a question about their bookings, it receives the booking and guest details needed to answer, and only ever for that one restaurant. The dietary field on a guest's profile is never sent; the free-text notes on a booking or guest profile are, if they are needed to answer the question. Anthropic does not use this data to train its models.

If a restaurant connects its Square account, we also receive customer and sales details from Square, matched to your booking by phone number or email, so that restaurant can see visits and spend together. That stays within the one restaurant's account.

If a restaurant connects its Google Business Profile, we receive that restaurant's own Google reviews from Google (the star rating, the review text, the reviewer's public display name and the date) so the restaurant can see them on its own dashboard next to the review requests we send for it. We read only; we never post, edit or reply on the restaurant's behalf. We do not link a Google reviewer to any diner record, we do not share these reviews with anyone else, and we do not use them for advertising. The restaurant can disconnect at any time from its settings or by revoking Tablekeep's access in its Google Account, and we delete the stored reviews when it does. Our use of information received from Google APIs follows the Google API Services User Data Policy, including its Limited Use requirements.

Analytics and what loads in your browser

This marketing site uses PostHog to count visits and see which parts of a page are used, including clicks and form submissions. It keeps no identifier beyond your browser tab session: no tracking cookie, no cross-visit profile, no advertising. The product itself runs no analytics and sets no tracking cookies, and the booking widget keeps nothing in your browser's storage. To tell a restaurant when its booking page stops being reachable, we count how many times it opens each day. The count is not linked to you, your device or your booking. The only third-party code it loads is listed above: the bot check, Stripe's payment form when a deposit is due, and error reporting.

Security and retention

Everything moves over encrypted connections, access is restricted per venue, and we keep automated daily backups. Tablekeep staff can open a restaurant's account to support it or fix a problem; that access is limited, logged, and used only for those purposes. We keep enquiry details only while they are useful for talking with you. Booking and guest data is kept for as long as the restaurant subscribes, then for 30 days after its subscription ends in case it returns, then de-identified. Restaurants can export their data at any time while subscribed, because it is theirs.

If you are in New Zealand

New Zealand's Privacy Act 2020 applies to how we handle personal information about people in New Zealand, including diners who book at a New Zealand restaurant that uses Tablekeep, even though we are based in Australia.

Your information is stored in Australia, with Supabase in Sydney. Storing it there does not take it outside New Zealand's protection: the Privacy Act 2020 applies to us wherever the information is held, and Supabase keeps it for us rather than using it for its own purposes. We also handle it under the Australian Privacy Principles. The providers listed above that work outside Australia each receive only what their job needs.

Booking details belong to the restaurant you booked with, so under New Zealand law that restaurant is responsible for them and we hold them on its behalf. If a privacy breach affects them, we tell the restaurant straight away and help it notify the Office of the Privacy Commissioner and the people affected. For information we hold for ourselves, such as venue accounts and enquiries, we notify the Privacy Commissioner and the people affected as soon as practicable whenever a breach has caused or is likely to cause serious harm.

Your rights

We handle personal information under the Australian Privacy Principles and, for people in New Zealand, the information privacy principles in New Zealand's Privacy Act 2020. You can ask what we hold about you, ask us to correct it, or ask us to delete it: [email protected]. If you are not happy with our answer, you can complain to the Office of the Australian Information Commissioner (oaic.gov.au) or, in New Zealand, to the Office of the Privacy Commissioner (privacy.org.nz), which asks that you raise it with us first.