Privacy Policy

This policy explains what the company that runs The Main Course (the "service") — "we" and "us" below — does with personal data. It forms part of our Terms of Service. It is written for three readers: restaurant owners who use the service, guests who book a table or order food through it (booked or ordered? section 6 is yours), and visitors to the websites it publishes.

What this policy does not cover: the websites restaurants publish through the service are the restaurants' own websites. What a restaurant puts on its site, and how it treats its own customers' information, is the restaurant's responsibility, under its own privacy notice — not ours.

1. The short version

• We collect what the service needs to build and run your website — and nothing for advertising. We have added no analytics, advertising, or tracking tools anywhere in the service, unless a restaurant turns on visitor counting for its own website — a setting that is off unless it is switched on, and whose own counting sets no cookies and stores nothing about the people who visit (section 7). The guest reservation and ordering pages carry nothing of the kind either way; we only count how often each is opened, with nothing about who (section 6). (Some content can still be loaded straight from other companies — a map, where a page shows one and the visitor presses to see it, and the check that a real person is signing in or, where we have switched it on, filling in a guest's form or writing to us from our website; sections 7 and 8 say which, and what those companies receive. The reservation and ordering pages load nothing from anybody but us, but for that check where it is switched on.)
• Your restaurant's details, menus, and photos are sent to the AI providers that write your pages and generate your images. That is how the product works, and section 9 names who they are and where they operate.
• Files you upload are publicly readable at their web address, because your website has to be able to show them. Don't upload anything confidential.
• Your guests' reservation and order details are stored for your restaurant, shown only to you and to the guest they belong to, and never used by us to reach out to anyone for a purpose of our own. The only messages the service sends a guest are emails about a reservation or a food order they made, in the restaurant's name, when they gave an email address with it, and the restaurant's own news by email, only to a guest who asked that restaurant for it and confirmed from their own inbox (section 6). Guests' requests about their data go to the restaurant they booked or ordered with.
• We never sell personal data, and we never share it for advertising. We run no ads and send no marketing of our own; a restaurant's news goes only to the guests who asked it for news (section 6). Nobody's card details reach us — paying for a plan happens on the pages of our payment provider, Stripe, and a guest paying a restaurant by card pays on Stripe's page too, into the restaurant's own account (sections 6 and 9).
• Deleting a website deletes its records, including its reservations, its orders and the files you uploaded. A little survives it — section 13 says exactly what and why, and how to ask about anything else.

If the summary and a section below ever disagree, the section wins.

2. Who is responsible for what

We wear two hats, and the difference decides who answers for what:

• For restaurant owners (your account, your answers, your website, your uploads), and for the operation and security of the platform itself, we are the business responsible (the "controller").
• For guests' reservation and order data taken by the built-in reservation and ordering systems, the restaurant is the business responsible (the controller) and we act on its behalf (the processor), including when we email a guest about their reservation or order. The commitments we make to restaurants for that data are in section 17 of our Terms of Service; what we actually do with it is section 6 below. One narrow exception — the abuse checks in section 6 — is our own responsibility as the platform's operator.
• For visitors to a published website, the restaurant that owns the website is responsible for it. Our role is infrastructure (section 7).

3. What we collect about restaurant owners

Your account. Your email address and password, and your name if you add one on your Account details page, held by our sign-in provider (Supabase); we never see or store your password ourselves, and your name is shown only to you. Our own records keep your email address, when the account was created and whether you have been shown round the builder, and the account records which versions of this policy and of our Terms of Service you agreed to when you created it, and when.

Your answers. Everything you tell the service about your restaurant so it can build your website: name, address, opening hours, phone and email for the business, cuisine and concept, menu text, delivery areas, links to your social and review pages, notes you type (for example, notes to the logo designer), and brand colors. If you use "Import from Google", we keep the place identifier, the overall rating and review count, and the link to your Google listing — individual review texts are never stored.

Your files. Menus, photos, and logos you upload, and the images generated for your pages. These are stored at web addresses that anyone who has the address can open — your website needs to display them, so do not upload anything confidential. Hidden camera metadata (such as GPS location) is removed from every picture you upload before it is stored, and a picture we cannot clean is refused rather than stored with it. A PDF, such as a menu, is stored as you uploaded it. These are kept until the website they belong to is deleted (section 13).

Your website and its history. Every version of every page the service builds or edits for you, kept so you can undo and restore — and, for each other language you add, your pages' words in that language and every version of them — and the messages you exchange with the builder's assistant. These are kept until the website is deleted, except that a page's earlier versions are thinned once they are more than a year old (section 13).

Your web address, if you move its settings to us. When you connect a bare web address (a "domain" — for example yourrestaurant.com without the "www."; Terms, section 9.3), we store the copy of your domain's existing records that we showed you for review — including email records — because managing the domain requires them.

Usage records. One record per action that counts against your plan's allowances, one per paid AI call, one for each publish and each change to a web address, and a running total of how much your account saved each day, so allowances and abuse limits can be enforced. These are account records, not behavioral profiles.

The emails we send you. We email the address on your account about your own work: reservations waiting for your answer (or every reservation a guest makes, changes or cancels, or none, as you choose in your reservation settings), new orders as they come in (unless you switch that off in your ordering settings), a month's allowance running low, your email marketing's emails to guests running low or run out, a change to your plan, and notices about the service itself. We keep a record of which of the last four we have sent, so none is sent twice. None of them is marketing. When you ask for a test of one of your restaurant's emails, it is sent to the address on your account and nowhere else, through Resend (section 9); we keep when it was sent and Resend's reference for it for 30 days, to limit how many go and to know a report about it is about a test.

When you write to us from Help. The Help panel's questions are answered on your screen, and nothing you press there is kept. When you write to us, we keep what you send: your answers to those questions, the website and the screen it is about, your message, the address you sign in with so we can reply, and a picture of your screen if you add one. A picture shows whatever was on your screen, so leave out anything you would not want us to see. A copy is emailed to our support inbox (section 9), and each message is kept until your account is deleted (section 13).

When anybody writes to us from our website. Our own website, the one that describes the service, has a page for writing to us, which anybody may use, with an account or without. We keep what is sent: the name and email address typed and the message, so we can answer, and, for about a day, a scrambled version of the network address it came from, to limit how many messages one place can send. A copy is emailed to our support inbox (section 9), and each message is deleted a year after it was sent (section 13), or sooner if the person who wrote it asks.

If you sell food through your website. Your shop's settings — the dishes and their prices, where you deliver and what that costs, when you take orders, and whether guests can add a tip — and, if you take cards, the identifier of your own Stripe account and whether Stripe says it can take payments. When you open that Stripe account through the service, we pass Stripe the email address you log in with and our reference for the website (section 9). Your guests' orders are section 6.

Your plan and what you have paid. Which plan your account is on and when it changed, and what our payment provider, Stripe (section 9), tells us about your subscription: which plan and billing period it is for, whether it is running, when the current period ends, any change you have booked for the end of it, and the identifiers Stripe uses for your customer and subscription records. We also keep a record of each message from Stripe we have acted on — its identifier, its kind and when it arrived — so none is acted on twice. You pay on Stripe's own pages, and the card never reaches us, so we hold no card number, no expiry date and no security code, and no amounts or invoices either. Where you give a billing address, a name or a tax number at Stripe's checkout, that is held by Stripe, which also keeps your receipts.

What we do not collect from owners: we store no payment card details, and the records our own application keeps hold no IP addresses or browser details for owners. The sign-in system records each sign-in session — including the network address and browser used — as part of keeping accounts secure; the check that a real person is signing in is Cloudflare's (section 8); and the infrastructure providers the service runs on may keep their own technical logs (section 9).

4. What we use it for, and on what legal footing

To run the service: build and publish your website, take your reservations and orders, email you about your reservations, your orders and your plan, enforce plan allowances and abuse limits, take payment for a plan and keep the records of it, keep the service secure, help you when you contact us, and meet legal obligations. That is the list. We do not use your data for advertising, we do not sell it, and we do not build profiles of you beyond what the features you can see on screen show you.

Where the law asks us to name a legal basis: we process owners' data to perform our contract with them (building and publishing the website, taking reservations and orders, taking payment, support); in our legitimate interests in keeping the service secure and preventing abuse (which is also the basis for the scrambled network addresses and the email count in section 6) and in answering anybody who writes to us from our website (section 3); and to comply with legal obligations (which is why records of what you paid are kept for as long as tax law requires — section 13). We process guests' reservation and order data on the restaurant's instructions, as its processor. Nothing we do rests on consent, so there is no consent to withdraw — if that ever changes, this policy will say so first.

None of this data is required by law. It is needed to provide the service: without an email address there is no account, and without your restaurant's details there is nothing to build a website from.

5. The AI providers that build your website

The service's whole point is that AI writes your pages and creates your images. Doing that sends your content to the AI providers that do the work:

• Text and page-writing — your restaurant's answers (including its name, address, phone, and hours), your menu text, your uploaded menu files and photos (which the AI reads to extract your dishes and to classify your photos), the pages being built, edited, checked or put into another language (your dish names only if you choose to have them translated), the instructions and messages you type to the builder, and — if you ask for help connecting a web address — that question, including your web address, the name of the company you bought it from, and the settings we ask you to add.
• Image generation — text descriptions built from your answers (for a logo, that includes your restaurant's name and your own logo notes). Your files are not sent to the image provider; only descriptions are.

Your guests' reservation and order data is never sent to any AI provider. The providers are named in section 9, including where they operate. We reach them through their business programming interfaces, under their standard business terms, and we ask them for nothing beyond the work described above.

6. Guests' reservation and order data (built-in reservations and ordering)

When a guest books a table through the built-in reservation system, we collect, on the restaurant's behalf: the guest's name, an email address or phone number (at least one, so the restaurant can reach them), party size, the time booked, and any note the guest types. The note is a free box ("Anything we should know?"), so a guest can put anything in it, health information such as an allergy included; it is stored with the reservation, shown only to the restaurant, and used for nothing else. If a reservation is later moved, the record also keeps what was first asked for — the earlier time and party size. The email address, where the guest gives one, is used for one more thing: to send the guest emails about that reservation (below).

When a guest orders food through the built-in ordering system, we collect, on the restaurant's behalf: the guest's name and phone number, an email address if they give one, whether the food is to be collected or delivered and when, what they ordered and what it came to (a tip included, where the restaurant lets guests add one), and — for a delivery — the address the food is going to, including anything they add about how to find them, such as a door or buzzer code. There is also a free box for the kitchen, so a guest can put anything in it, health information such as an allergy included. All of it is stored with the order and shown only to the restaurant. The email address is used for one more thing, and nothing else: to send the guest emails about that order (below).

No card details reach us. Where a restaurant takes payment when the food is handed over, no payment passes through the service at all. Where it takes cards, the guest pays on Stripe's own page, into the restaurant's own Stripe account (section 9). We tell Stripe the amount, the restaurant's name, our reference for the order and the address of the guest's private order page, which is where Stripe sends the guest back to; Stripe tells us whether the payment went through, and we keep that and Stripe's reference for the payment with the order. If the restaurant turns down or cancels an order that has been paid for, the service refunds it through the same account. We take no share of the payment.

If you are a restaurant using built-in reservations or ordering: your guests' reservation and order data is collected for you, and telling your guests how it is used — your own privacy notice — is your responsibility, not something this policy does for you (Terms of Service, section 17).

What we do — and deliberately do not do — with it:

• It is shown only to the restaurant, on its own reservation sheet or orders board — and to the guest who made it, through their own private link. It never appears to other guests or the public. We set no cookies and use no browser storage on the reservation or ordering pages, we load no trackers there, and those pages fetch nothing at all from another company — no lettering, no scripts, no images from anyone but us — except, where we have switched it on, Cloudflare's check that a real person is making the reservation or the order (section 8). A guest paying by card leaves them for Stripe's own page. The hosting infrastructure the pages are served through (section 9) may set its own operational cookies, which we do not control.
• We count how often those two pages are opened: each time a guest opens a restaurant's reservation form or ordering page, one is added to a count for that restaurant and that day, so the restaurant can see it. Nothing about the guest is kept with the count.
• A guest who books a table and gives an email address is sent emails about that reservation, and nothing else. They are sent in the restaurant's name, on its behalf: when the reservation is made, when the restaurant confirms it, turns it down, moves it or cancels it, and, unless the restaurant turns reminders off, about a day before the table. They carry the restaurant's details, the date, time and party size and the confirmation code; they also carry the guest's first name and, while the reservation stands, the private link to it. They repeat nothing else the guest typed — not the phone number or the note. A reply goes to the restaurant. A reservation the restaurant enters itself is sent nothing. They are sent through Cloudflare (section 9), and there is never marketing in them. (If a guest writes to us, we answer — see the end of this section; and where the law requires a notification, section 12 applies.)
• The restaurant can be emailed about its reservations, at the address on its own account: when a reservation waits for its answer, or whenever a guest books, changes or cancels, if it chooses that, or never, if it switches them off. Those emails name the guest by first name only and carry the date, time, party size and confirmation code; the guest's email address, phone number and note stay on the restaurant's reservation sheet.
• A guest who orders food and gives an email address is sent emails about that order, and nothing else. They are sent in the restaurant's name, on its behalf: when the order is taken, when a card payment for it arrives, and when the restaurant accepts it, turns it down, cancels it, has it ready to collect or sends it out. They carry the restaurant's details and the order's number and, while the order is going ahead, what was ordered, what it came to and the private link to the order; the first also carries the guest's first name. They repeat nothing else the guest typed — not the delivery address, the phone number or the note for the kitchen. A reply goes to the restaurant. They are sent through Cloudflare (section 9), and there is never marketing in them.
• Before a reservation or an order is taken, the guest may be asked to confirm their email address. Where the service sends email, the form sends a six-digit code to the address the guest typed, in the restaurant's name, and the reservation or order goes ahead only once the guest types that code back. What is kept to check it is a scrambled version (a hash) of the address and of the code, for that restaurant, with how many times it was tried; neither the address nor the code is stored as such, a code works for half an hour, and the record is deleted a day later. To stop the codes being used to flood somebody's inbox, one address is sent no more than five in an hour, and the network address the code was asked from is kept with it in scrambled form only (a keyed hash), so that no one place can ask for more than thirty in an hour. The email carries the code and nothing else the guest typed, and there is never marketing in it. Checking that an address belongs to the person giving it is part of keeping the reservation and ordering systems working (section 2), so for this we are the business responsible, on the basis of our legitimate interest in that.
• The manage link is stored in scrambled form (a hash) to check it with, and, once it has been emailed to the guest, also in encrypted form, so a later email about the same reservation or order can carry it again. Because it travels in a web address and in those emails, it can appear in technical logs (section 12).
• The network address a reservation or an order comes from is used to limit abuse (too many from one place) and stored only in scrambled form (a salted hash) with the reservation or the order; each press of "Pay now" is counted the same way, in a separate record of the scrambled address and the restaurant that is kept for about a day. The raw address is not written to our database. So that no inbox is flooded, the service also counts how many reservations, and how many orders, were made with the same email address at any restaurant over the day before, and emails one address about no more than ten of each in a day; that count is worked out from the records above and keeps nothing of its own. These are operational safeguards, not anonymization. Limiting abuse of the reservation and ordering systems is our own responsibility as the platform's operator (section 2), so for these uses we are the business responsible, on the basis of our legitimate interest in keeping the service secure and working.
• The restaurant's reservation sheet can group past reservations by matching contact details, so the restaurant can see how often a guest has been in. This is computed when the sheet is read — no guest profile or guest account is stored — and a missed visit is only ever what the restaurant itself marked.
• Reservation and order records are kept for the restaurant and delete with the restaurant's website (section 13). A guest cancelling marks the reservation or order cancelled; it stays with the restaurant as its record of what was booked or ordered.
• The restaurant can delete what it holds about a guest, itself, at any time, and it chooses between two things when it does: deleting the name, email address, phone number, any note left with the reservation and the scrambled network address it came from — which leaves the reservation on its sheet as a table for a number of people at a time, with nothing on it about who — or deleting those reservations outright. It can do this for one reservation or for everything one guest has ever booked. Neither can be undone, and nothing anywhere keeps a copy of what was deleted. Where the details go and the reservation stays, it keeps its seats, its confirmation code and the scrambled version of the guest's own manage link — so the restaurant's covers stay right, and a link the guest already has still opens a reservation with nothing on it about who made it.
• A restaurant can also set a standing rule that deletes those details on any reservation older than a length of time it chooses. This is off unless the restaurant turns it on, it deletes details rather than reservations, and it is carried out while the restaurant is using the service rather than at a fixed moment — so it is a rule about what is kept rather than a promise about exactly when.
• For an order, the restaurant can delete the guest's details itself, one order at a time: the name, phone number, email address, delivery address, the notes and the scrambled network address. The order stays, with what was ordered, what it cost and Stripe's reference for any payment, but nothing about who ordered it, and no more emails can be sent about it. It cannot be undone. There is no standing rule for orders.

A restaurant's news, for guests who ask for it. A guest can ask a restaurant for its news (new dishes, events, offers) by email, where the restaurant asks: with a switch on its reservation form or at its checkout, which is off until the guest turns it on, on the confirmation of a reservation or an order, on the reservation's or the order's own page, or on the restaurant's own sign-up page (which a card printed for its tables can open). We then keep, on the restaurant's behalf: the email address, a first name if the guest gives one, a birthday if the guest gives one (the day and the month, never the year), which of the restaurant's locations and which language the request came from, when they asked, confirmed and stopped, and the date of their latest reservation or order there (which can be one still to come).

• Nobody is added until they confirm from the inbox itself. Asking sends one confirmation email, and only the link in it, and a press on the page it opens, puts the guest on the list. A request nobody confirms is deleted after 30 days. So that nobody is flooded by somebody else typing their address, one email address is sent at most three confirmations a day across every restaurant, counted from the records above.
• The restaurant writes the messages: its newsletters and, where it switches them on, a welcome when a guest confirms, a thank-you the morning after a reservation or an order, a birthday message, a message to a guest who has not reserved or ordered for a while, and news of dishes it adds to its menu. To know whom to thank and who has been away, the restaurant's own reservations and orders are matched to its list by the email address; nothing more is kept for it. They are sent in the restaurant's name, and every email carries the restaurant's postal address and a link to stop. A message the restaurant leaves in our standard words is sent in the language the guest asked in.
• Emails are sent through Resend (section 9). We do not track who opens a message or presses a link in it: there is no tracking picture and no link is rewritten. The pictures in an email (the restaurant's logo, a picture of its own, its dishes' photos) come from our own address, the same for every guest.
• What a newsletter brought in is counted, not watched. For each newsletter, the restaurant is shown how many reservations and orders the guests it reached made in the two weeks after it, beside the same guests' two weeks before it, and how often a discount code it carried was used. These are totals, counted from the restaurant's own reservations and orders, matched by the email address; nothing is kept about any one guest, and nobody is shown who.
• Stopping is always one click, and nothing more is sent after it: the link in every email (a mail program's own "unsubscribe" button uses it too) or the page it opens. The restaurant can also take a guest off its list at any time. A stopped guest's address stays on the list, marked stopped, so that nothing is sent to it again unless the guest asks again and confirms.
• We keep a record of each message sent (to which address on the list, when, and whether it went) for up to 400 days, to hold each account to the number of emails its email marketing add-on includes and to send a birthday message only once a year. The list itself is kept while the restaurant's website exists and deleted with it (section 13).
• Texts have stopped. A guest could once also ask for a restaurant's news by text message, sent from the restaurant's own Twilio account. No texts are sent any more. A mobile number given then is never used and never shown to the restaurant: nothing is sent to it, it is deleted with the restaurant's list (section 13), and a guest can ask us to delete it sooner (section 14).

If you booked a table or ordered food (guests): the restaurant you booked or ordered with is responsible for your data, and requests about it — access, correction, deletion — go to the restaurant first. Asking it to delete what it holds about you is something it can do itself, straight away, without us. If you cannot reach the restaurant, contact us and we will pass your request to it and help it respond, as its processor.

If a restaurant connects a third-party reservation provider (rather than the built-in system), reservations happen on that provider's own pages under that provider's own privacy policy — that data never reaches us.

7. Visitors to published websites

Websites built with the service are published as the restaurant's own website. For visitors to those sites:

• The pages are served by our hosting provider (section 9), whose infrastructure handles every visitor request and keeps its own technical logs. We add no analytics, advertising, or tracking tools to published pages unless the restaurant turns on visitor counting for its own website (the next bullet); the third-party content named below that is loaded by the visitor's browser from those companies directly.
• Visitor counting is off unless a restaurant switches it on, and what it does is narrow. With it on, the restaurant's pages carry a small piece of our code that reports which page was opened, whether the visitor had just arrived at the site and, where they arrived from another website, the name of that website — never the full address they came from, which is the part that can carry search terms. Our code sets no cookie, uses no browser storage, and stores nothing that identifies a person: no network address, no browser fingerprint, and no identifier of any kind, hashed or otherwise. What is kept is a daily count per page for the restaurant to look at. With counting on, the pages can also load Cloudflare Web Analytics, which measures how quickly the page loaded for that visitor; the visitor's browser fetches it from Cloudflare directly, so Cloudflare receives the visitor's network address, under its own privacy policy. The restaurant chooses this for its own website and can switch it off again, which removes both at its next publish.
• A page that shows a location map shows a box in its place, saying that the map comes from Google Maps, until the visitor presses to see it. Only then does the visitor's browser connect to Google, which means Google receives the visitor's network address, under its own privacy policy, and may set its own cookies inside the map. Nothing about that press is remembered, so the box is there again on the next visit.
• Typefaces are not one of these. The typefaces a page is set in come from Google Fonts, and when a website is published our servers fetch them once and copy them into the website itself, so loading them reaches nobody but the site's own hosting. Where a publish could not copy one, that text is shown in a standard typeface rather than loaded from Google. A website that has not been published since this began still loads its typefaces from Google, and its visitors' network addresses reach Google, until it is published again.
• Ready-made photographs are not one of these. The photographs the service puts on a page when a restaurant has none of its own are ours, and wherever a publish can manage it they are copied into the published website itself — so loading one reaches nobody but the site's own hosting. Where a publish could not copy one, it loads from our storage instead, which is the next point.
• Pages normally carry their own styling software and photos, but this is best-effort: a website can end up loading its styling software, on every one of its pages, from Tailwind Labs, the company that publishes it, and some images — including the picture shown when the site's link is shared in a message or on social media — from our storage. In each case the connecting browser's network address reaches that service.
• If the restaurant uses built-in reservations or ordering, the reservation form and the ordering panel on its site are served through our systems — that is section 6. If it takes reservations through Setmore or SimplyBook.me instead, its site shows that company's own reservation page, and for SimplyBook.me runs a small piece of that company's software, so the visitor's browser reaches that company directly (section 9).

Everything else about a published website — what it says, what it links to, and the restaurant's own obligations to its visitors — is the restaurant's, under its own privacy notice.

8. Cookies and what stays in your browser

The builder — the signed-in part of the service where owners make their website — uses functional cookies only; there are no advertising or analytics cookies anywhere in the service:

The builder also keeps a few small conveniences in your browser's own storage: the web address you told us you had bought or were about to buy, a saved list of suggested website improvements and which of them you switched on, the web addresses whose email warning you have already read, whether you have been shown round the builder, whether you turned down the offer to design a logo or already had one drawn, whether you folded the builder's side panel away, which kinds of panel and figure each of your Analytics screens showed the last time you opened it (the kinds only, never a number, a name or anything about your guests), whether each website's Analytics and Orders screens showed a row of its locations and how many letters each location's name had (never the names), display preferences such as whether times are shown as 12- or 24-hour, and whether the orders screen on that device makes a sound for new orders. While a page is being built, it also keeps that the build has started and how far it has got — the short name in the page's web address, the figure and the words shown beside it — so that reloading the builder can finish the build, and it clears that once the build is over. And for as long as a browser tab stays open, it keeps which half of the builder's panel you were looking at, so reloading the page brings it back. These stay in your browser: they are conveniences, not records — the service never treats them as the truth about your account. Each of these, like the cookies above, exists only to do something you asked for, which is why we show no cookie banner.

For each website you open in the builder, it also remembers how that screen was laid out the last time you saw it, so it can show where its buttons will be while it opens: which step you were on, the names of the steps and which of them your plan does not include, the words on its buttons, whether the site was online and whether at our demo address or your own, how many lines the restaurant's name took up, how many chat messages there were, and how many buttons the row of your pages had, how wide each one was and whether its Add a page button was open or locked. It never keeps the web address, the restaurant's name, your pages' names, the messages or anything else you wrote.

If you turn that sound on, your browser may ask whether the service can show you notifications. A notification is shown by your own browser on that device, only while the orders screen is open in it, and says only the restaurant's name, the order's number, whether it is for delivery or takeaway, and its total: never anything the guest typed.

When you look at a preview, or a small picture, of your own website inside the service, your browser loads that page's typefaces from Google Fonts directly, so Google receives your network address; the copy a publish makes is what your visitors get. A map on the page loads from Google Maps only once you press to see it, as it does for a visitor.

The screens where you sign in, create an account or ask for a new password run Cloudflare Turnstile, a check that a real person rather than an automated program is at the keyboard. Your browser loads it from Cloudflare and runs it there, so Cloudflare receives your network address and what the check reads from your browser, under its own privacy policy; our sign-in provider then asks Cloudflare whether the check was passed before it lets the request through. It is there to keep automated sign-ups and sign-in attempts out, and we use it for nothing else.

Where we have switched it on, the same check also runs on the forms a restaurant's guests fill in: the reservation form, the ordering page, the email code a guest is sent before a reservation or an order is taken, and a restaurant's news sign-up page. It starts when the guest begins to fill in the form, in a small frame of ours that loads it from Cloudflare, so Cloudflare receives the guest's network address and what the check reads from their browser, under its own privacy policy; we then ask Cloudflare whether the check was passed before we take the reservation, the order, the request for a code or the sign-up. Most guests are asked nothing, and a few are asked to press a box. It is there to keep automated reservations, orders and sign-ups out, and we use it for nothing else.

Where we have switched it on, the same check also runs on our own website's page for writing to us, in the same frame of ours, once the person writing presses Send: Cloudflare receives their network address and what the check reads from their browser, under its own privacy policy, and we ask Cloudflare whether the check was passed before we keep the message.

Because the service follows nobody from page to page or site to site, there is nothing for a "Do Not Track" or Global Privacy Control browser signal to switch off; we do not respond to those signals, and nobody is followed either way. Visitor counting, where a restaurant has turned it on for its own website (section 7), does not change that: it counts pages, not people, and keeps nothing that could tell one visitor from another.

Your guests get none of this: we set no cookies and use no browser storage at all on the reservation and ordering pages, and none on a published website either — visitor counting included. The whole service — the builder, the reservation and ordering pages and published websites alike — is served through hosting infrastructure (section 9) that may set its own operational cookies for security and traffic handling, which we do not control; and where the check that a real person is filling in a form is switched on (above), it runs under Cloudflare's own policy.

9. Who receives data (our providers)

The service runs on a small number of providers. This table is the current list, and we keep it current. The rows marked (guest data) are also the subprocessor list for guests' reservation and order data that our Terms of Service (section 17) promise: before the providers handling guests' reservation and order data change, we tell restaurant owners — by email to the address on the account, by a prominent message inside the service, or both — so they can object.

The companies that run the AI text model. OpenRouter hands each request to the first of these that can answer it, in this order, and to no other company, even when none of them can — and only where OpenRouter lists that company as keeping nothing it is sent:

• Inceptron AB (Lund, Sweden), which says it processes requests only inside the European Union and the European Economic Area
• Baseten Labs, Inc. (San Francisco, United States), which does not say which countries its computers are in
• AutoInfra, Inc., trading as Morph (San Francisco, United States)

A note about your files. Uploads and generated pictures live in storage in the United Kingdom, but they are served from a public web address so your website can show them — which means copies are also kept for a time on Cloudflare's network around the world, close to whoever is looking. Your guests' reservation and order details are not files and are never served this way.

Beyond these providers, we disclose personal data only: when the law requires it; where necessary to enforce our Terms of Service or to establish, exercise, or defend legal claims; to protect the rights, safety, or property of the service, our users, or others; to professional advisers under confidentiality; or to a successor who takes over running the service under the same terms (Terms, sections 11.5 and 18.4). We never sell personal data — a successor receives it only to keep running the service, which can happen as part of a sale of the business itself, never as a sale of the data.

10. Where data goes in the world

Our providers operate in several countries, and using the service moves data between them: the database, sign-in and the files' home are in the United Kingdom — though the files themselves are served from a public web address, so copies of your photos, logos, menu files and the pictures we generate are also held for a time on Cloudflare's network, wherever is nearest the person asking for them; the hosting of published websites runs on Cloudflare's global network, which handles each request in whichever country is nearest the person making it; the service itself runs on the same network, where each request arrives wherever is nearest the person making it and is then handled beside the database, in or near the United Kingdom; images are generated in the United States; and AI text requests go through a relay in the United States (OpenRouter), which passes each one on to one of the companies section 9 names as running the GLM models, in Sweden or the United States — though Baseten does not say which countries its computers are in, so a request it answers may be processed in another.

Three more things leave those countries by a different route. Checking whether a web address is free, and working out who you bought one from, sends that address to the public directories the world's domain registries keep — including registries in the United States, the United Kingdom and the Netherlands. Looking up a web address's current settings sends it to Cloudflare's public directory service. And wherever a browser loads a map a visitor asked to see, a typeface in a preview inside the builder, or the software a page is styled with where a publish could not copy it into the website, the browser doing the looking reaches Google or Tailwind Labs in the United States directly, from wherever that browser happens to be.

Section 5 says what is and is not sent to the AI providers; guests' reservation and order data stays with the storage and hosting providers — and, for a payment by card, the restaurant's own Stripe account — and is never part of the AI flows.

11. What we never do

We do not sell personal data, and we do not share it for cross-context behavioral advertising (the "sharing" some US state laws regulate). We show no advertising and use no advertising or analytics trackers. We send no marketing of our own. We never reach out to a restaurant's guests for a purpose of our own: the only messages a guest receives from the service are emails about a reservation or a food order they made, and the restaurant's own news by email where the guest asked that restaurant for it and confirmed, all sent in the restaurant's name (section 6). We do not use guests' data for our own purposes beyond running and securing the service (section 6). We store no payment card details: paying for a plan happens on Stripe's own pages (section 9), and the card number never reaches us. What we know about your payments is what section 3 lists — which plan you are on and the state of your subscription.

12. How we protect data — and the limit of that promise

Protections built into the service include: guests' reservation and order records are designed to be readable only by our own server code, not directly from a browser; third-party reservation credentials are stored encrypted; guests' network addresses are stored only in scrambled form, and their manage links scrambled and, once emailed, encrypted (section 6); hidden photo metadata is stripped as section 3 describes; and the sign-in system is operated by a dedicated provider. Web addresses requested from our systems — which can include a guest's manage link — can appear in technical logs kept by us or our infrastructure providers; ours are short-lived, and theirs are kept on their own schedules (section 13).

No promise of absolute security is made or should be believed — from anyone. No method of storing or transmitting data can be guaranteed secure, and we do not guarantee it. If we become aware of a breach affecting data we process for a restaurant, we tell the restaurant without undue delay (Terms, section 17); where the law requires us to notify anyone else, we do.

13. How long we keep things

Plainly: things are kept until you delete them or the thing they belong to. Three small records that exist only to limit abuse are the exception, and clear themselves as the service runs: the scrambled network address behind a guest's press of "Pay now" (section 6), and the one behind a message written to us from our website (section 3), are each kept for about a day, and how much each account saved on a given day for about a week. The messages written to us from our website, which belong to no account, are deleted after a year. Your pages' oldest earlier versions are thinned too, as the list below says. The nearest thing to an exception beyond those is a standing rule a restaurant can switch on for itself (section 6) — and that is carried out while the restaurant is using the service rather than at a fixed moment, so it is a rule about what is kept rather than a clock.

• Your answers, pages, page history (in every language you added, thinned as the next item says), assistant messages, domain and publishing records, your uploaded files, your shop, and your guests' reservations and orders are kept while the website exists, and deleting the website deletes them — including every guest reservation and order record, and including the pictures, menus and logos you uploaded and the images we generated for your pages.
• A page's earlier versions are thinned after a year. Once a version of a page, in any language, is more than a year old it is deleted, unless it is one of the hundred newest versions of that page in that language, or is still in use (the version you are working on, the one on your live website, or the one a translation was made from). So you can always go back to any moment in the last year, and to a page's last hundred versions whenever they were made. The pictures those versions used stay until the website is deleted.
• One thing stays behind by design: where we look after a web address's settings and they have gone live, deleting the website leaves them with Cloudflare, still answering for your web address and its email, until you move them back (Terms, section 9.7).
• A restaurant's list of guests who asked for its news is kept while its website exists and deleted with it; a request nobody confirmed is deleted after 30 days, and the record of each message sent after 400 (section 6).
• Messages you write to us from Help are kept with your account and deleted with it (section 3).
• Messages anybody writes to us from our website are deleted a year after they were sent, and the scrambled network address kept with each after about a day (section 3). We delete one sooner when the person who wrote it asks.
• Guest details are also deletable on their own, by the restaurant, for one reservation or for one guest's whole history, and by the standing rule above. Both are described in section 6. Neither can be undone.
• Deleting a website does not delete your account; closing your account (Terms, section 16) deletes your account data within 30 days, including your files in storage. Closing an account is currently done by contacting us, and completing it is a manual process on our side.
• Records of what you paid outlive all of this, for as long as tax and accounting law requires them to be kept. They are records of a transaction, not of your website, and the detail — amounts, receipts, the card — sits with Stripe (section 9) rather than with us.
• One thing outlives deleting a website, and this policy would rather say so than be tidy: usage records (plan and AI metering) are kept as account records for 90 days and then deleted, except the record of what a free account has used of its one-time allowance, which is deleted with the account (above), as is the record of which notices we have emailed you (section 3). Your files used to outlive it too; deleting a website now removes them as part of the deletion. Copies held on the network that serves your website stay reachable for a while afterwards, because they are cached close to whoever was looking (section 10), and copies in our routine backups clear when those cycle out. If anything looks to you like it is still there, tell us.
• If the service itself closes, the data it holds is deleted (Terms, section 11.2).
• Our infrastructure providers keep their own technical logs on their own schedules, which we do not control.

14. Your rights and choices

Depending on where you live, the law may give you rights over your personal data — to see it, correct it, receive a copy you can take elsewhere, have it deleted, limit what we do with it while a question about it is resolved, object to a use of it, or complain to your data-protection authority. We honor these where the law provides them:

• Owners: some of it you can do yourself — your answers and website are editable in the service, your name, your password and the email address you log in with can be changed on the Account details page under the account button (for a new address, a link goes to the old address and the new one, and it changes once both are pressed), and deleting a website or closing your account (section 13) is deletion. For anything else, including receiving a copy of your data, write to us.
• Anybody who wrote to us from our website: to see, correct or delete what you sent, write to us again from the same page.
• Guests: your restaurant is the business responsible for your reservation or order — start there (section 6). Deleting what it holds about you is something it can do itself, in the service, without waiting on us. We help it respond, and we will pass on a request you send us.

California and some other US states give their residents similar rights. We do not sell personal information and we do not share it for cross-context behavioral advertising, we use no sensitive personal information beyond running the service, we keep things only as section 13 describes, and we never treat anyone differently for exercising a right. To exercise one, use the routes above.

The service makes no decisions about you by automated means that have legal or similarly significant effects.

15. Children

The service is for businesses and its account holders must be at least 18. It is not directed at children, and we do not knowingly collect children's data. A guest booking a table or ordering food provides only the details in section 6; the reservation and ordering pages are not directed at children, and if we learn we hold a child's details in a way the law does not allow, we will tell the restaurant and help it put that right.

16. Changes to this policy

If we change this policy in a way that reduces your protections or expands what we do with personal data, we tell owners at least 30 days before it takes effect — by email to the address on the account, by a prominent message inside the service, or both — the same way the Terms of Service change (Terms, section 18.5) — and because this policy forms part of the Terms, such a change carries the same right: if you do not agree, you may cancel before it takes effect. Changes that only describe the service more accurately — a provider named in section 9 changing, a new feature being described — take effect when posted, and the date at the top says when. Where our Terms require advance notice of a change (the subprocessor list for guests' reservation and order data — Terms, section 17), that notice is always given, through the ways section 9 describes.