Privacy policy: what we keep and why

In short

This page says what ResOlio keeps about guests, restaurants and visitors to this site, why the law allows it, how long it stays, who else handles it, and what you can ask for.

Last updated 7 October 2026

Who answers for your data.

For a booking it is the restaurant you booked with; for everything else on this page it is Hi Dev Mobile Inc., the company behind ResOlio.

Bookings and guest records: The restaurant decides what happens to them, and we keep them for it as its processor.
Accounts, this website and our own mail: Hi Dev Mobile Inc., 24 E. 25th Avenue, San Mateo, CA 94403, United States, decides, and answers to you directly.
Reaching us: Write to hello@resolio.app about anything on this page.

Three details about a guest are required.

There is no payment field anywhere in the product, on any plan.

Name: Required. The restaurant sees it on the booking and on the list for the evening.
Email address: Required. The confirmation, the reminder and the link to change the booking go there.
Phone number: Required, so a guest without one cannot book online.
The booking itself: Party size, date, time and restaurant, and afterwards how the evening ended.
A request, if they have one: Optional free text, up to five hundred characters, passed on exactly as typed.
A dietary note, if they give one: Optional, chosen from the fourteen allergens European labelling law names plus “other”, each marked allergy, intolerance or diet.
Two consents: The box that has to be ticked to book, and an optional marketing box, each stamped with the moment it was ticked. The product has no marketing mail to send under the second.
A count of visits: How many evenings a guest sat, cancelled or missed, kept on every plan and shown on Pro.
A rating, if they leave one: After a finished visit, the booking’s own link asks how it was: a mark from one to five and an optional comment, which the restaurant reads and can never change.
Nothing else: No postal address or date of birth is asked for, and no IP address or device fingerprint is kept against a booking.

What we keep about people who sign in.

A restaurant’s login, a guest’s own account and a visit to this website each keep a little, and no more.

A restaurant’s login: The email address and name it signs in with, a password only as a one-way hash, the devices named on it and each change they made.
A guest’s own account: The email address and name, the bookings made with it, and anything its holder adds to their profile.
Support messages: What a restaurant writes to us from the office, and our replies.
A visit to this website: No analytics. Our host sees each request and the internet address it came from, as any web host does, and keeps its logs only briefly.
A page that breaks: Which screen broke and why, with email addresses, phone numbers and private links taken out first.

Other owners never see your guest book.

Two restaurants under one owner share a guest book; two owners never can.

Your restaurant: Sees each booking on the service screen and in the office, and can tell which device opened a record.
A tablet: Reads a guest’s record to serve them, and can never merge, export or erase one.
Another owner: Never. Each account recognises its guests by its own one-way key.
What outlives an address: The unsubscribe list, a no-show mark and an erasure receipt, which hold only that key.

Mail about the guest’s own booking.

Nothing is sold or used to advertise.

The confirmation, with a calendar file and a link to change or cancel
A notice if the booking changes or is cancelled
The reminder before the evening
Waiting-list mail, for a guest who joined one
On Pro, a message the restaurant writes from the booking

The reason the law accepts for each use.

Every use of personal data here rests on one of four grounds the GDPR names.

To keep an agreement: Taking and changing a booking, sending its confirmation and reminder, and running a restaurant’s or a guest’s account.
With consent: The dietary note, which can say something about health and so needs the guest’s explicit consent, and a restaurant’s news. Either can be withdrawn at any time.
In a legitimate interest: Keeping the service secure, stopping abuse, finding what breaks, and answering a message sent to us.
Because the law requires it: The records a tax authority may ask for, once paid plans are charged.

Twenty-four months after somebody stops being a guest.

Contact details are deleted on a schedule, and the booking they belong to stays.

Contact details and dietary note, for a guest with no account and nothing booked24 months
A no-show mark, and the key it carries12 months
The sent-mail log’s copy of an address13 months
The office’s record of which device changed what24 months
A message sent through the contact form24 months

What a guest can do alone, and what needs your restaurant.

An account holder’s contact details are never cleared on a clock.

Closing an account

Unlinks the login from every restaurant’s record of them
Clears the profile they built: seating preference, dietary list, favourites
Disables the login

A restaurant’s own login cannot be closed this way; it would lock the owner out of their office.

Erasing a record

Runs from the office, and never from a tablet on the bar
Cancels anything upcoming, and puts those tables back into the evening
Clears the name, the contact details and every word the guest typed
Clears the notes, tags and dietary record a Pro plan keeps

The date, time, party size and outcome stay, and the address leaves the sent-mail log too, once the last email to them has gone out or been stopped.

How a guest’s data is deleted

What you can ask for.

Ask the restaurant about a booking and us about everything else, and the answer comes within a month.

A copy of what is held about you, in a file you can take elsewhere.
A correction, or the erasure of what no longer needs keeping.
That a use stops, for now or for good, where you object to it.
To withdraw a consent, which changes nothing done before.
To complain to the data protection authority where you live or work.

Ask us

One cookie, and it is for staff.

There is no analytics, advertising or tracking cookie, and no tracker of any kind, anywhere in the product.

The one cookie: Called sidebar_state and set only in the office, for a week, to remember whether staff left the navigation open. A guest booking a table never gets it.
A sign-in: The token that keeps a staff login or a guest account signed in, held in browser storage until you sign out.
The device: In the office, which restaurant the browser is showing and the name you gave the device, so every change says where it was made. Switching notifications on also registers the device to receive them.
A booking in progress: A random id per restaurant that keeps a held table held and, in that tab only, the confirmation and the link to change the booking. The restaurant’s own website cannot read any of it.
Unsaved work: An office form not saved yet stays on that device until it is saved or discarded, so a flat battery loses nothing. The floor-plan editor also marks its tab, so two windows never edit the room at once.
Preferences: Light or dark and, on staff screens, how each was last laid out, from the guestlist’s order to the floor’s zoom, the chime and the hints already closed. None of it is about a guest.

Who else touches it.

Four companies receive any of it.

Convex: The database and the backend. Every booking and guest record lives there, and nowhere else.
Vercel: The hosting. It serves ResOlio’s website, each restaurant’s booking page and the booking overlay, and like any web host it sees the requests that reach it.
Resend: The email provider. It is handed the recipient’s address and the message going to them, and nothing else about the guest.
Better Stack: Error reports. When a page or a background job breaks, it is told which screen and what went wrong, with email addresses, phone numbers and private links taken out first, and, as any web service is, the internet address the report came from.
Google, when live: Only for someone who chooses Sign in with Google: Google learns they signed in to ResOlio, and we receive the name and address on that account.

Kept in the United States, under the EU’s safeguards.

Hi Dev Mobile Inc. and the four companies on this page are in the United States, so data from Europe is transferred there.

Each transfer is covered by the European Commission’s standard contractual clauses, or by the EU–US Data Privacy Framework where a company is certified under it. Write to us for a copy of the clauses that apply.

Children, automated decisions and changes.

Three last things, each said once.

ResOlio is not meant for children: a guest’s own account is only for people sixteen or older.
The one decision software makes alone is a rule a restaurant can switch on: asking a guest with repeated no-shows to book by phone rather than online.
When this page changes in a way that matters, its date at the top changes, and anyone with an account is told by email.

A person answers.

Write to us about any of it, including a line you think is wrong.

What your restaurant holds

A guest’s question about their own record comes to you first: it is your guest book, and you can answer faster than we can.

The software itself

Anything about the software goes to hello@resolio.app, answered within one business day. The contact form keeps what you send until its own clock runs out, or until a person deletes it on request.