This policy describes what Gilded Plate holds about people, why, who can see it, how long it is kept, and what you can do about it. It covers diners who order from a table and restaurant staff who run a restaurant on Gilded Plate — and they are often the same person, so one policy rather than two that would drift apart.
It is written from the software, not from a template. Where it says what the system does, that is what the system does.
Gilded Plate is operated by Gilded Plate LLC, 137 Rancho Deluxe, Liberty Hill, TX 78642, United States. Write to us at support@gildedplate.com.
1. Who controls what — read this first
There are two different relationships here, and mixing them up is the quickest way to misunderstand everything below.
Your Gilded Plate account is ours to look after. One account works at every restaurant on Gilded Plate, so the relationship is between you and us. Everything in section 2 — your account, your devices, your visits, your saved needs, your sign-in credentials — we are the controller of.
Your orders belong to the restaurant you ordered from. The restaurant decides what to do with its own order records, and we process them on its behalf, as its service provider. If you want an order record changed or removed, that is a conversation with the restaurant.
Three consequences worth stating plainly:
- A restaurant cannot see your account. The console shows a restaurant the name and email address of someone who was signed in when they ordered from it, and nothing else from section 2 — not your saved dietary needs, not your devices, not your visits elsewhere, not your card identifiers.
- Deleting your account does not delete the restaurant's order records. The order stays as the restaurant's record of a sale, with your columns emptied so it no longer points at you.
- A restaurant can take a copy of its own records. Exporting its data is the restaurant's right, not yours as a diner: the export carries its orders as its console shows them, with the name and email address of a diner who was signed in, and never anything else from section 2.
2. Diners: what we hold
2.1 An account is created when you first scan
The first time you scan a table's QR code, we create an account for that phone. It has no name, no email address and no sign-in — just an identifier. We do this so a returning diner can be recognised, so your orders are attributed to you, and so saved needs can follow you.
This is a disclosure, not a request for consent: the account holds nothing personal until you give us something. Personal details arrive only when you sign in; health data arrives only when you switch it on (section 3).
2.2 The device token
A cookie called guest_device names your phone to us. It holds an
identifier and a secret; the secret is stored on our side only as a hash. It
lasts 400 days and refreshes as you use it. It is what lets us recognise
the phone across visits, and it carries no authority to order or to pay.
2.3 Visits
Each scan records which location, and when. The restaurant's analytics count how many diners were returning — never who. A restaurant sees totals, not a list of people.
2.4 The card fingerprint
When you pay by card, Square gives us an opaque identifier for that card. It is not a card number, not an expiry date, not a name — it cannot be turned back into any of those, and it is useless to anyone else. We keep it so that paying with the same card on a different phone recognises you as the same person.
Nobody sees it. It appears on no console, admin or station screen, and an automated test walks our source code on every change to keep it that way.
2.5 If you sign in
Signing in adds what you give us: an email address, and optionally a name and phone number. Depending on how you sign in, we also hold a Firebase Authentication user (for email and password, Google, Apple or phone) and, if you create one, a passkey — a public key and a credential id, never anything that could sign in as you elsewhere.
2.6 When two records become one
If we can tell that two accounts are the same person — the same card on two phones, or you signing in on a phone that had been ordering anonymously — we merge them, and record why: which account survived, which was absorbed, and what the evidence was. That record is ours alone; no restaurant sees it.
We are deliberately cautious. Two signed-in accounts that share a card are not merged (that is a couple, not a person), and a phone that has seen two different cards is not merged into either.
2.7 Orders, and the event log
An order you place while signed in is linked to your account. Sessions you start are recorded. Our operational event log records things like a claim, a merge or a prompt, by identifier only — never by name or email — and restaurant staff see the events at their own location.
2.8 Connected apps
If you connect an application — an AI assistant, say — through our permission screen, we hold the grant and its tokens, and the app can do only what you allowed. You can disconnect it at any time from your connections, which ends its access.
3. Dietary needs — health data, and how it is handled
This section stands on its own, because it is the most sensitive thing Gilded Plate touches.
Allergens you avoid, whether you want "may contain" items hidden, and the diets you follow are health data. Halal and kosher additionally say something about religious belief. We treat all of it accordingly.
By default, they never leave your phone. When you set them while browsing a menu, they are stored in your phone's own browser storage. They are not put in the web address, not put in a cookie, and not sent to us or to the restaurant. The menu is filtered on your phone.
They reach your account only if you ask. Either you turn on the switch on Your needs, or you answer "keep these" when we offer at a table. Nothing else does it — no automatic copy, and never an app or an assistant acting for you. Until you do, those fields on your account are empty.
Turning it off empties them immediately. The same switch, off, clears the three fields and the record of your consent in the same write. There is nothing left to un-tick later.
Who sees them: you. An application you have explicitly granted profile access. Never a restaurant — a restaurant sees a filtered menu, not the reason it was filtered.
4. Restaurant staff
A staff member's account is the same kind of account as a diner's — because it is often the same person, ordering lunch at one restaurant and running another. It holds a name, email address, phone number and sign-in credentials, and sign-in runs through Firebase Authentication.
What a restaurant sees of its own people is what it needs to run: who is on staff, what role and permissions they hold, which location they work at, and what they did in the console and on the station screens. Your dietary needs, your visits as a diner and your orders elsewhere are not part of that.
When a restaurant closes. A restaurant that ends its plan is closed for 60 days and locked for 60 more, and is then deleted, its staff records with it (our Restaurant Terms, clause 14). Your own account is not deleted with it — it is yours, and you can go on using it. Before that, the restaurant may export its records, which include its staff list with each person's name and the email address they sign in with, and their time on the clock. From the deleted restaurant we keep our own records of our relationship with it for at least 10 years, and among them the name and email address of the person who owned it at the time it was deleted, so we can show who we dealt with.
5. Cookies
Gilded Plate sets four cookies, all of them functional. There is no tracking cookie, no advertising cookie, and no third-party cookie.
| Cookie | What it is for | How long |
|---|---|---|
session | Keeps you signed in | 7 days |
table_session | Ties your phone to the table you scanned, so your basket and order belong to it | 4 hours |
guest_device | Recognises your phone across visits (section 2.2) | 400 days |
station_session | Keeps a restaurant's shared device paired to that restaurant | 365 days |
There is no cookie banner because there is nothing to ask about. Our website analytics measure page views in aggregate and set no cookie at all — that is precisely why they were chosen over the alternative.
Your dietary needs use your browser's own storage rather than a cookie (section 3), which means they are never sent with a request.
6. Who else processes data
These are the companies our software sends data to in order to work. The list below is generated from the same list our engineers maintain in the code, so it cannot quietly fall out of date.
| Who | What they do for us | Since |
|---|---|---|
| Square | Card payments and the connection to your Square account. Sees card details and payment amounts; we see only the token and the charge id. | 2026-08-03 |
| Google Firebase | Sign-in for everyone with an account — restaurant staff, and diners who create one by email, Google, Apple or phone number — and the live-update signal that tells the kitchen board and a diner's order page that something changed. The signal carries a timestamp and nothing else — no order contents. | 2026-08-03 |
| Neon | The Postgres database where menus, orders, sessions and staff permissions are stored. | 2026-08-08 |
| Vercel | Hosts the application and stores uploaded images (menu photos and logos). | 2026-08-08 |
| Resend | Sends the emails Gilded Plate writes to you — receipts, sign-in links, invitations — and holds the address and the message to deliver it. | 2026-09-10 |
7. What you can do, and how
Everything here is self-service and immediate. There is no form to fill in and no ticket to wait on.
| What | Where |
|---|---|
| Get a copy of everything | Your data — one file, downloaded there and then |
| Delete your account | Your data |
| Correct your name or phone number | Your account |
| Change or withdraw dietary needs | Your needs |
| Manage how you sign in | Ways to sign in |
| Disconnect an app | Connections |
What deletion does. In one step we remove your devices, passkeys, sign-in links, card fingerprints, visits and merge records, delete your sign-in account, empty your details, strip your identifier from our event log and replace the device identifier on past events with a fresh random one, and sign you out. Your orders and sessions stay as the restaurant's records, with your columns emptied (section 1).
One real limit. We cannot delete an account that is on a restaurant's staff or that holds a platform-administrator flag — a restaurant would lose an operator mid-service. The page says so, and names the restaurants. Ask them to remove you first, then delete.
8. How long we keep things
A scheduled job runs daily and applies these limits. Being "seen" means using Gilded Plate.
| What | Kept until |
|---|---|
| An account that never signed in | 365 days after it was last seen |
| An account that did sign in | 730 days after it was last seen, with a warning email 30 days beforehand |
| A staff member's or administrator's account | Not deleted by this job at all |
| A phone's device record | 400 days after it was last seen |
| An unused sign-in link | A day after it expires |
| An email we sent you | 90 days, then the address and the message are removed from it |
| An email that failed to send | 30 days, then it is deleted |
About the emails. We keep an outbox of what we have sent you — a receipt, a sign-in link, a retention warning — so a failed send can be retried and so we can tell whether a receipt reached you.
After 90 days the row is stripped rather than deleted: the address is reduced to its first letter and its domain, and the message itself is emptied. What is left is the bare fact that a receipt was sent on a date, which is the part a restaurant's order page shows and the part that stops us emailing the same receipt endlessly. An email that failed to send is deleted outright after 30 days.
Orders and their receipts are the restaurant's records and are kept on its behalf (section 1) until the restaurant closes and is deleted, normally 120 days after its plan ends (section 4). What we keep after that — our own records of the restaurant as our customer, and the name and email address of its owner at the time — we keep for at least 10 years after the deletion.
9. Children
Gilded Plate is for ordering food in restaurants and is not directed at children. We do not knowingly create accounts for children under 13. If you believe we hold a child's details, write to us and we will remove them.
10. Where data is held
Gilded Plate is operated from the United States and the services in section 6 process data there. We currently serve US restaurants only.
11. Changes to this policy
A published version of this policy is never edited. If it changes, we publish a new version with a later effective date and this one stays as it was, so what was true on a given day remains readable. The date it took effect is at the top of this page.
Unlike the restaurant terms, this policy is not something you accept — it is a description of what we do, and nothing in Gilded Plate will ever ask you to agree to it.
12. Contact
Questions, or a request we have not made self-service: write to support@gildedplate.com, or to Gilded Plate LLC, 137 Rancho Deluxe, Liberty Hill, TX 78642.