RISTHORALegal
Risthora Privacy Policy
Risthora Privacy Policy
Last updated: 22 October 2026.
Risthora is an online platform for restaurants: booking pages, offer pages, a staff panel for the day's service, an administration console, communications with guests and marketing tools. It is provided by ZETAVISION S.R.L., Via Don Leone Serafini 44/2, 38121 Trento (TN), Italy, VAT number IT02806560229 ("ZetaVision", "we", "us").
This policy explains what personal data Risthora handles, who is responsible for it, why it is used, who receives it, how long it is kept and how to exercise your rights. It is written for:
- restaurants that use Risthora and the people who use Risthora for them: owners, managers and agency members (together, "staff users");
- guests who book a table or ask for an offer on pages powered by Risthora;
- visitors of those pages.
1. Who is responsible for your data
Many restaurants use Risthora. The data of each restaurant is kept separate from the data of every other restaurant. Who is responsible depends on the kind of data:
| Data | Controller (decides why and how it is used) | ZetaVision's role |
|---|---|---|
| Guests' data: bookings, contact details, notes, consents, preferences, messages, waitlist entries, offer requests, check-in | The restaurant the guest books with or contacts | Processor: we process it only on that restaurant's instructions, to provide Risthora |
| Other people's data a restaurant chooses to keep in Risthora, such as applicants to its franchise | That restaurant | Processor |
| Data a restaurant obtains from accounts it connects itself, such as its Meta advertising account | That restaurant | Processor |
| Staff user accounts: email address, password (kept only as a hash), role and locations, sign-in sessions, language and display preferences, security records | ZetaVision | Controller |
| The business relationship with each restaurant: its contacts, agreements, support requests and, where fees apply, invoicing | ZetaVision | Controller |
If you are a guest, the restaurant is your first point of contact. Its own privacy notice is linked from its booking form. Section 9 explains how requests reach us.
Our processing on behalf of restaurants is governed by the data processing agreement under article 28 GDPR that ZetaVision concludes with each restaurant. A restaurant can ask for a copy at marco.filippo@zetavision.it.
2. What Risthora stores for a restaurant
- Configuration: locations, opening hours, rooms and tables, availability rules, the booking form and the optional questions it asks, communication settings and message templates.
- Identity and branding: the restaurant's name, logo, colours, the links shown at the foot of its pages, and its web addresses.
- Offers and their pages, with earlier versions and the conversations held in the offer studio.
- The media library: photos and videos the restaurant uploads or creates in Risthora. When a photo is uploaded it is re-encoded, which removes embedded information such as the GPS location. Photos in the library are meant for public pages and can be opened by anyone who has their web address. Files attached in the studio chats (offers and communications) are never added to the library on their own: they are kept privately, and become library photos only when the restaurant chooses to use them. A picture kept only as a reference is never shown on a page or in an email.
- Staff accounts and their roles, and the invitations sent to new members.
- Audit records: who did what in the restaurant's console (for example an invitation, a change of role, a publication). They contain no guests' data.
- AI usage records: for each call to an AI provider, the feature, the provider and model, the cost, the size of the request, the time taken and the outcome. They never contain the text of a request or of an answer.
- Connections the restaurant sets up: its own email server settings, its Google Analytics and Meta Pixel identifiers, its settings for sending booking events to Meta, and its Meta advertising connection (section 6). Passwords and access tokens are stored encrypted and are never shown again, not even to the restaurant.
- Reports and figures computed from the above.
3. What Risthora stores about guests, on behalf of the restaurant
- Booking details: the location, date and time, number of guests, status (for example confirmed, cancelled or no-show), how the booking was made (online, by phone, at the door), the offer or coupon used, the language, and, at check-in, the time of arrival and the number of guests actually seated.
- Identity and contact: name, email address and phone number.
- What the guest writes or answers: notes, dietary requirements (which can reveal health information, such as an allergy), and the answers to optional questions the restaurant chooses to ask (for example a high chair, a dog, a special occasion).
- Consents: the optional consent to receive promotional emails from that restaurant, with the time and the site where it was given; and the choice made in the cookie banner about advertising measurement.
- Where the visit came from, only if the guest accepted cookies: the campaign labels in the link (UTM parameters), advertising click identifiers (from Google, Meta, Microsoft or TikTok), the referring page, the landing page, the type of device and the browser's language.
- A contact record for each email address at that restaurant: how many bookings, visits and no-shows and their dates; and, where the restaurant uses these features, a short note written by its staff, a "VIP" or "review" mark, and the day and month of the guest's birthday if the guest gives it on their preferences page. The year of birth is never asked.
- Communication preferences and opt-outs, and a list of addresses to which reminders and promotional messages must not be sent, because they bounced, complained or were blocked by the restaurant.
- A record of each message: which message went to which address, when, and its delivery result (for example sent, delivered, bounced). Risthora does not record whether a message was opened or which links were clicked.
- Waitlist entries, requests to receive one offer by email (the email address only), and the answer to the short satisfaction survey (a score from 1 to 5) where the restaurant sends one.
Risthora does not take card payments from guests: the card guarantee and deposit feature present in the software is not active.
4. Why we use data, and on what legal basis
4.1 When ZetaVision is the controller
| Purpose | Legal basis |
|---|---|
| Creating and managing staff accounts, signing in, keeping the console secure | Performance of the contract with the restaurant (art. 6(1)(b) GDPR); for staff users who are not party to that contract, our legitimate interest in giving the people the restaurant authorises a secure service (art. 6(1)(f)) |
| Security records, prevention of abuse, audit records | Legitimate interest (art. 6(1)(f)); legal obligations (art. 6(1)(c)) |
| Support and service communications with the restaurant | Performance of the contract (art. 6(1)(b)) |
| Measuring, in aggregate and without cookies, how fast pages load, to improve the service | Legitimate interest (art. 6(1)(f)) |
| Invoicing and accounting, where fees apply | Legal obligation (art. 6(1)(c)) |
4.2 When the restaurant is the controller
The restaurant decides why its guests' data is used and states the legal bases in its own privacy notice. Risthora is built for these uses: taking and managing bookings; sending confirmations and reminders; check-in at the door; statistics for the restaurant; promotional emails only to guests who opted in; and measuring advertising only for guests who accepted cookies.
5. Artificial intelligence features
Risthora includes AI features that answer questions about the restaurant's reports, propose offers, pages and messages, describe and create images, and read the screenshots a restaurant sends to correct a page.
- What is sent to AI providers: aggregate statistics, audiences described as filters and counts, the restaurant's own texts, and the photos, videos or screenshots the restaurant chooses. Guest profiles, guests' names, contact details and individual bookings are not part of what is sent.
- A technical check before anything leaves Risthora: a request that contains an email address, a phone number or a field reserved for a guest's data is refused, and nothing is sent. This check cannot recognise every name written in free text, so staff must not type guests' personal data into AI features.
- Photos used to create new images must not show recognisable people.
- What we keep: the AI usage records described in section 2, never the content of requests or answers. Proposals and the owner's decisions stay in the restaurant's account.
- Providers (section 7): text and the reading of images use models hosted by DigitalOcean. Some of these models are made by Anthropic, which keeps the requests and the answers for 30 days. The creation of images and short videos uses Higgsfield. Under Higgsfield's standard terms, what it receives and what it produces may be used to train its models, and content already used for training cannot be withdrawn.
- The restaurant can see which providers are in use at any time, on the console page "Artificial intelligence and privacy".
- AI never publishes, sends or spends by itself: accepting a proposal prepares a draft, and publishing, sending or activating anything needs a further action by the owner. Pictures created with AI carry a label on the pages guests see and in advertisements.
- Screenshots sent for a visual correction are kept private and are deleted with the studio session, at the latest 30 days after upload.
6. Data from Meta (Facebook and Instagram)
Only an owner of the restaurant can connect the restaurant's Meta account, from the Connections page of the console, through Meta's own login dialog. Risthora never sees the Meta password.
- What Risthora receives: an access token for the person who connected; the list of permissions granted; the businesses, advertising accounts (with their name, currency and time zone), Pages and pixels that the token can see; and, for each ad and each day, the names and identifiers of the campaign, ad set and ad, the amount spent, the impressions, the clicks and the results.
- What it is used for: letting the owner choose which advertising account to read, and showing the restaurant, beside its own bookings, what each campaign and each ad cost and what it brought. Nothing else. Today Risthora only reads: it does not create, change or pay for advertising, and it does not post content.
- What is never done with it: it is not sold, not shared with other restaurants and not used to build profiles of people. Account identifiers and tokens are never given to AI providers; aggregate results per campaign and per ad may be part of the figures the restaurant asks Risthora to analyse.
- How it is protected: the token is stored encrypted and is never shown to anyone, the restaurant included.
- How to remove it: an owner can press "Disconnect" at any time. Risthora then deletes the token and the connection details at once and asks Meta to withdraw the permissions granted. The app can also be removed from the restaurant's business settings at Meta. See the Data Deletion Instructions at https://risthora.com/data-deletion.
Booking events sent to Meta. Separately, a restaurant may choose to send booking events (a booking made online, its confirmation, the guest's arrival) to its own Meta dataset. This is off unless the restaurant switches it on. When on, it concerns only online bookings by guests who accepted advertising cookies. An event carries the advertising click identifier and, only for guests who also gave promotional consent, their email address and phone number in one-way hashed form. No IP address is sent. The restaurant must name Meta as a recipient in its own privacy notice before switching this on.
Risthora does not publish to Instagram or Facebook and does not build advertising audiences with Meta today. This policy will be updated before either is switched on.
7. Who receives data
| Recipient | What for | What it receives | When |
|---|---|---|---|
| DigitalOcean | Hosts Risthora's application server and database, in its Frankfurt region | All the data Risthora stores | Always |
| DigitalOcean (AI models) | Runs the AI models for text and for reading images | What section 5 describes, never guests' data | When the restaurant uses AI features |
| Anthropic, through DigitalOcean | Makes some of those models; keeps requests and answers for 30 days | As above | When those models are in use |
| Higgsfield | Creates images and short videos | The photos the restaurant chooses and the description written for them | When the restaurant creates images |
| Vercel | Hosts Risthora's web pages, with its page servers in its Frankfurt region, and measures page speed without cookies | The pages and requests passing through it | Always |
| Brevo | Sends the emails of restaurants that use Risthora's own sender | The recipient's address and the message | For each message |
| Resend | Sends the emails of restaurants that use their own Resend account, and is Risthora's fallback sender | The recipient's address and the message | For each message |
| The restaurant's own email server | Sends the restaurant's emails, if it set one up | The recipient's address and the message | For each message |
| Cloudflare | Stores the off-site copy of the nightly database backup | Backup copies | Every night |
| Meta | Only if the restaurant connects or enables it: reading its advertising data (section 6), its Meta Pixel on its pages after cookie consent (section 10), booking events to its dataset (section 6) | As described in sections 6 and 10 | Only when connected or enabled |
| Only if the restaurant adds its Google Analytics identifier: statistics on its pages | As described in section 10 | Only when enabled | |
| Risthora Operations, ZetaVision's restaurant management product | Only if the restaurant also uses it | Booking codes, times, table codes and number of guests; never a guest's identity | Only when connected |
| The restaurant's agency, if it works with one | Prepares drafts of offers, pages, images and campaigns for the restaurant | The restaurant's content and aggregate marketing results; agency members never see guests' data | Only if an owner grants access |
| Tools the restaurant connects itself (API keys, AI assistants through Risthora's MCP connection) | Whatever the restaurant uses them for | What the restaurant's key allows | Only if the restaurant connects them |
Some features are built into the software but are not active for any restaurant today: WhatsApp reminders (through Meta), Reserve with Google, and card guarantees and deposits (through Stripe). This policy will be updated before any of them is switched on.
ZetaVision staff access restaurants' and guests' data only to operate, secure and support the service and to carry out a restaurant's instructions, such as an erasure.
We disclose data to public authorities only where the law requires it, and only the data the request legally requires.
8. How long data is kept
These periods are the same for every restaurant.
| Data | Kept for | Then |
|---|---|---|
| A guest's name, email, phone, notes, dietary requirements, answers and click identifiers on a booking | 36 months after the booking's date | Replaced by a pseudonym; the booking's date, number of guests, status and offer stay as the restaurant's records |
| A guest's contact record and preferences | 24 months after the guest's last booking | Deleted |
| Message records and planned messages | 24 months | Deleted |
| A closed waitlist entry | 30 days after it closes | Deleted |
| A request to receive an offer | 30 days after the offer's last day | Deleted |
| Booking events prepared for Meta | 30 days after they are sent or given up | Deleted |
| Addresses that bounced or complained | As long as the contact exists; afterwards only as a one-way digest | Kept, so that reminders and promotional messages are not sent to that address again |
| Private chat attachments, references and screenshots kept from the studio chats (not in the photo library) | 30 days from upload, and up to 90 days more in the off-site copy | Deleted |
| Deleted photos and videos | 30 days in the trash, during which they can be restored | Removed for good, unless something still uses them |
| The working context of the Risthora AI assistant | 30 days after its last change, or until the person leaves the restaurant | Deleted |
| The Meta advertising connection (token and account details) | Until an owner disconnects it | Deleted at once |
| Advertising spend already read | As long as the restaurant's account exists | Deleted with the account |
| Staff accounts, audit records and AI usage records | As long as the restaurant's account exists | Deleted with the account, except records the law requires us to keep |
| Backup copies of the database | Made every night; kept on our server for 14 days, with an off-site copy at Cloudflare for 90 days and an archive on ZetaVision's own storage in its office in Italy, both for disaster recovery | Deleted from our server after 14 days and from the off-site copy after 90 days; the office archive has no automatic deletion date yet. A backup is never put back into the live service except to recover from an incident, and then every erasure made since is applied again |
| Server logs | Rotated by size: older entries are overwritten as new ones are written | Overwritten |
ZetaVision applies these periods with a dedicated retention procedure, run periodically.
9. Your rights and how to exercise them
Under the GDPR you have the right to access your data, to have it corrected or erased, to restrict or object to its processing, to receive it in a portable format, and to withdraw a consent at any time. You can also lodge a complaint with a supervisory authority: in Italy, the Garante per la protezione dei dati personali (www.garanteprivacy.it), or the authority of the country where you live or work.
Guests
- Ask the restaurant you booked with. The restaurant forwards an erasure request to ZetaVision on the day it receives it, and ZetaVision carries it out. You can also write to us at marco.filippo@zetavision.it; we forward your request to the restaurant within two working days.
- The legal deadline for an answer is one month from the day the restaurant received the request.
- To stop promotional emails at once, use the link at the end of any reminder or promotional email. It opens your preferences page; nothing changes until you press the button there.
- If you booked at more than one restaurant, each restaurant decides separately about your data, and each needs its own request.
- What an erasure does: your name, contact details, notes and answers are removed from that restaurant's bookings and replaced by a pseudonym, so the restaurant keeps the dates and the number of guests for its records but not you; your contact record, preferences, waitlist entries and offer requests are deleted; message records keep only their date and result; and a one-way digest of your address and number is kept, so that an opt-out or a block you had stays in force and a later import cannot bring back your bookings or your consent. The erasure is done in one step that either completes entirely or changes nothing.
- What an erasure in Risthora cannot reach: copies held by email providers, Meta and Google under their own terms; copies in backups and server logs until they are deleted or overwritten (section 8); and systems the restaurant used before Risthora.
Staff users and restaurants
Write to marco.filippo@zetavision.it. You can change your password and your console language yourself, and an owner can remove a member from the restaurant at any time.
10. Cookies and similar technologies
On a restaurant's booking and offer pages, the restaurant decides which measurement tools are used and is responsible for them; Risthora provides the technology. A banner asks visitors to accept or reject analytics and marketing cookies. The choice can be changed at any time from the "Cookies" link at the end of the page, and rejecting removes the measurement cookies already written.
| Name | Purpose | When | Duration |
|---|---|---|---|
| risthora_consent (browser storage) | Remembers the cookie choice | When the visitor chooses | Until the visitor clears it |
| rst_attr (cookie); rst_attr_first and rst_attr_last (browser storage). Until 20 April 2027 the same values may also be found under their former names, ibr_attr, ibr_attr_first and ibr_attr_last, which are read and then removed | Remember which campaign or link brought the visitor, so that a booking can be attributed to it | Only after the visitor accepts | 180 days for the cookie; the browser storage until the visitor clears it |
| The restaurant's Google Analytics cookies (_ga, _ga_*) | Statistics for the restaurant | Only after the visitor accepts. Before that, Google's script runs in a restricted mode that writes nothing on the device, and Google may still receive basic information about the visit without cookies | As set by Google: _ga up to 2 years |
| The restaurant's Meta Pixel cookies (_fbp, _fbc) | Measuring visits and bookings that come from Meta ads | The pixel is not loaded at all before the visitor accepts | As set by Meta: _fbp and _fbc up to 90 days |
| risthora_attesa | Carries a waitlist offer to the booking page | When the visitor opens a waitlist offer link | 30 minutes |
| Vercel Speed Insights | Measures how fast pages load; stores nothing on the device | Always | None |
Pages reached through a personal link (the preferences page, the page to change a booking, the survey, a waitlist offer) load no measurement tools at all. When a restaurant embeds the booking form in its own website, the choice made in that website's banner may be passed on to the form.
In the staff console, Risthora uses a sign-in cookie (staff_session, 30 days) and remembers the console's language and theme (risthora_console_locale and risthora_console_theme, one year). They are needed to provide the console.
11. Security
- Each restaurant's data is separated inside the database by row-level security. The server works out which restaurant a request belongs to from the web address, never from what a browser claims.
- Passwords are stored only as salted scrypt hashes. Sessions are signed and expire after 30 days, and changing a password ends the sessions opened before. Roles and permissions are checked again on every request, and the number of sign-in attempts is limited.
- Passwords and access tokens that a restaurant stores (for example its email server password or its Meta token) are encrypted with AES-256-GCM and are never shown again.
- Connections to Risthora use HTTPS.
- Staff actions are recorded in an audit log that the application can add to but cannot change.
- Records of AI calls contain no content.
- Photos are re-encoded on upload, which removes embedded location data.
12. Transfers outside the European Economic Area
Risthora's application server, database and web page servers run in the Frankfurt region (Germany). Some providers listed in section 7 are established outside the European Economic Area or do not state where they process data: for example, DigitalOcean does not state where its AI models run, and Higgsfield does not state its processing region. Where data is transferred outside the European Economic Area, the transfer relies on the safeguards in that provider's data processing terms: an adequacy decision of the European Commission (including the EU-US Data Privacy Framework, for certified providers) or the European Commission's Standard Contractual Clauses.
13. Changes to this policy
We publish every change on this page with its date. Material changes are also announced by email to restaurant owners at least 30 days before they take effect.
14. Contact
ZETAVISION S.R.L.
Via Don Leone Serafini 44/2, 38121 Trento (TN), Italy
VAT number IT02806560229
General contact: admin@zetavision.it
Privacy contact: marco.filippo@zetavision.it
ZetaVision has not appointed a data protection officer, as the GDPR does not require one for its activities.