Parlor

Privacy Policy

Effective 30 August 2026 · Last updated 1 October 2026

Parlor is restaurant operations software: reservations, floor management, event planning and the client pipeline, sold to venues. Venues put their own data and their guests' data into it. That data belongs to the venue, not to us — we hold it so the software can do its job, we do not sell it, and we do not use one venue's data for another's benefit.

Two different roles

It matters which of these two things we are doing, because it decides who you should ask about what.

• For venue staff accounts, we decide. If you work at a venue and sign in to Parlor, the account itself is ours to run — this policy covers it, and you can bring us your questions directly.
• For guest data, the venue decides. Bookings, guest records, event details and everything else a venue puts into Parlor belong to that venue. We process it on their instructions. A guest asking to see or delete their information should ask the venue; if a guest asks us, we pass it on to the venue rather than acting on it ourselves.

What we hold for venue staff accounts

• Your name and work email address, which identify the account.
• Your password, stored only as a cryptographic hash — we cannot read it, and neither can anyone who obtains the database. Signing in with Google, or with an emailed sign-in link, means we hold no password for you at all.
• Which venue you belong to and what you are allowed to do in it — the difference between an owner who can change booking settings and a member who cannot.
• Google account tokens, if you connect Google. See below.
• Ordinary service records — when you signed in, and the technical logs any hosted application keeps in order to stay up and to be debugged when it is not.

What venues put in, and what we do with it

A venue's Parlor account holds reservations and their guests' contact details, waitlist entries, the floor plan and table state, catering and event records, quotes and invoices, message templates, and the venue's own settings. We use it to provide the software and for nothing else. Specifically, we do not sell it, we do not share it between venues, we do not build advertising profiles from it, and we do not use it to train AI models.

We access a venue's data ourselves only in three situations: to fix a fault they have reported, to prevent or investigate abuse or a security incident, or where the law requires it.

Connecting Google

A venue can connect a Google account to Parlor. When it does, Parlor asks Google for two things, and only these two:

• Google Drive — only the files you pick. When you choose a picture or a document from your Drive to use in an email, Parlor can open that one file. It cannot see, list or search the rest of your Drive. (Google calls this permission drive.file.)
• Google Calendar — only the events you add. When you tap to add a catering event, a quote due date or a menu due date to your calendar, Parlor creates that event. It does not read the rest of your calendar. (Google calls this permission calendar.events.)

Gmail, for test accounts only. A small number of venues that test new Parlor features with us — today only Parlor's own first venue — also give Parlor permission to save email drafts in their Gmail and to read their Gmail inbox (gmail.compose and gmail.readonly). Parlor uses the first to put an email it has written for the venue into the venue's own Drafts folder, and the second only when the venue asks it to scan the inbox for new enquiries. No other venue is asked for Gmail access. For everyone else, Parlor gets an email ready on screen and the venue copies it, or opens it in their own email app, and sends it themselves.

We store the keys Google issues, and we use them only for the purposes above and only for the venue that connected them.

Parlor's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. In plain words: we use what Google shares only to provide the features described above, which the venue can see and control; we do not sell it; we do not use it for advertising; we do not use it to train AI models; and no person at Parlor reads it unless the venue asks us to (for example, to fix a problem they have reported), it is needed for security, or the law requires it.

For test accounts with Gmail, there is one part of this a venue should understand before using it. When a venue asks Parlor to scan for new enquiries, Parlor reads every message in that inbox for the chosen window — two to five days, up to a hundred messages — and sends the sender, the subject, the date and the first thousand characters of each one to Anthropic, which is what decides whether a message is a catering enquiry. This is done only to give the venue the scan it asked for, and Anthropic does not use it to train models. Nothing filters for relevance first, because relevance is the question being asked. A venue that scans a shared or personal mailbox should expect unrelated mail in that window to be included.

We do not retain copies of a mailbox: what is kept is the enquiry records the scan produces, not the messages it read. Disconnecting is a single action inside Parlor and revokes our access immediately; a venue can also revoke it from their Google account's security settings, which we honour just the same.

Artificial intelligence

Parlor uses AI to draft text a person then reviews and sends: quote emails, menu descriptions, reply drafts, briefings. The material needed to write a particular draft is sent to Anthropic to produce it.

Two commitments about this. It is not used to train models. And it drafts — it does not send: a person at the venue reads every AI-written message before a guest ever sees it.

Who we use to run Parlor

These are our subprocessors. Each holds data only to perform the function named.

• Supabase — database and authentication.
• Netlify — application hosting and the server functions.
• Twilio — sending text messages.
• Google — Drive (the files a venue picks) and Calendar for venues that connect them, and Gmail for test accounts only; Google Analytics for usage of our own pages.
• Square — deposits, invoices and payments. Card details go to Square and are handled under Square's terms; Parlor never sees or stores a card number. A venue that switches on guest spend from Square lets Parlor copy its completed Square sales (totals, tip, time and check name only — no items or card details) and the names, email addresses and phone numbers of the Square customers on those sales, so its staff can see what a guest has spent. Parlor never adds those customers to any email list. Switching it off, or disconnecting Square, deletes the copy.
• Anthropic — the AI drafting described above.

If we add or change a subprocessor in a way that materially affects venue data, we will update this list and tell the venues it affects.

Analytics on our own pages

Parlor's pages use Google Analytics to record which pages are opened, from roughly where, and on what kind of device.

Several Parlor pages carry a capability token in their address — a link that can cancel a guest's booking, accept a held table, or resume a signed-in session. Analytics on its own would send the whole address, token and all, to Google on every page view. Parlor strips those tokens before anything is sent, in one shared piece of code that every page uses rather than a rule each page has to remember. We mention it here because it is the kind of thing a policy usually leaves out and an operator ought to know.

Where data is held, and for how long

Parlor's data is held with our subprocessors above, whose infrastructure is in the United States. A venue outside the United States should take that into account.

We keep a venue's data for as long as their account is open. If a venue leaves, we will export their data to them on request and then delete it. Parlor has a per-venue retention setting for guest records; we will say plainly that nothing in Parlor currently deletes guest records automatically on a schedule, so a venue that needs a retention period enforced should ask us rather than assume it is running.

Security

Traffic is encrypted in transit. The database is not reachable from a browser: every read and write goes through Parlor's own server code, which authenticates the caller and resolves them to exactly one venue before touching anything. Passwords are hashed, never stored in a readable form. Google tokens are stored encrypted.

If we become aware of a breach affecting a venue's data, we will tell that venue without undue delay and with what we actually know, so they can meet their own obligations to their guests.

Your rights

If you hold a Parlor staff account, you can ask us to show you what we hold about that account, correct it, or close it and delete it. Where local law gives you further rights — portability, objection, or a complaint to a data protection authority — ask us and we will help you exercise them.

If you are a guest of a venue that uses Parlor, ask the venue. They hold the relationship and the decision, and we act on their instructions. We will help them respond.

Children

Parlor is a business tool sold to venues and is not directed at children. We do not knowingly collect information from anyone under 13 through our own accounts.

Changes to this policy

We will update this page and change the date at the top when this policy changes. Where a change materially affects how venue or guest data is handled, we will notify venues directly rather than relying on them to notice.

Contact us

Miz Kathi's Cotillion guest privacy policy