Acceptable Use Policy
This policy forms part of the Terms of Service between Datatreehaus and the business that accepts these documents through the Thezi dashboard. It applies to you, to everyone who signs in under your account, and to any software acting under a key you have issued. Defined terms have the meaning given in the Terms of Service.
Effective date: 11 September 2026
Acceptance: no printed signature is required. This policy is accepted by electronic confirmation in the dashboard, in accordance with clause 15.1 of the Terms of Service.
1. Permitted use
1.1 You may use the dashboard and the API to view, create, amend, move and cancel bookings for your Venue, to configure your tables, floor plan, services, opening times and policies, to manage marketing consent, and to apply or waive Cancellation Fees in line with your own published policy.
1.2 The Services are licensed for the Venue or Venues on your account only. You may not use them for another site, another business, or on behalf of a third party.
2. Your account
2.1 Each person who uses the dashboard must have their own sign-in. Do not share one login between people.
2.2 Every action is recorded against the account or key that took it. Sharing a login destroys that record and makes it your problem rather than ours: everything done under your account is treated as your action.
2.3 You must:
- give access only to people who need it, and remove it when they leave;
- choose a password you do not use anywhere else;
- not write credentials down anywhere visible to customers or the public; and
- tell us immediately if you think an account or key has been exposed.
3. API keys and automated agents
3.1 You may issue API keys, including keys marked as belonging to an automated agent rather than a person. This is a supported way to run your Venue and we encourage it.
3.2 An agent acting under your key is you. Every booking it takes, every change it makes and every message it sends to a Diner is your action and your responsibility. "The software did it" is not a defence under this policy.
3.3 You must:
- issue a separate key per agent or integration, so one can be revoked without breaking the others;
- mark an agent key as an agent key, so the audit record is truthful;
- revoke a key that is no longer needed, or that may have been exposed; and
- keep an agent within the same limits a member of your staff would have.
3.4 You must not use a key to poll the Services more often than the work requires, to bulk-extract data, or to work around a rate limit.
3.5 Derive idempotency keys from the booking, as the API documentation describes. An agent that retries with a fresh key each time will seat the same party twice, and that is a booking you will have to honour.
4. Diner information
4.1 Use Diner information only for fulfilling and managing bookings at your Venue, and for marketing where section 5 permits it.
4.2 The notes field may contain allergy, dietary and other health information, which is sensitive information under data protection law. Use it only to prepare for the Diner's visit, share it only with staff who need it, and never use it for marketing, profiling, or any purpose the Diner would not expect.
4.3 Do not record health information about a Diner anywhere else in the Services. No other field is designed to hold it, and the extra protections the notes field carries — the consent wording, the retention setting — do not follow it if you type it into a name or a booking reference.
4.4 Do not export, copy or transfer Diner information to another system or third party except as permitted by your own privacy notice and your data protection obligations.
4.5 Card data in your payment provider account is yours to manage. We do not delete or alter it. If a Diner asks you to erase their data or to remove a saved card, action that with your provider yourself. Deleting a booking in the dashboard does not remove anything from your provider.
4.6 The waitlist is the same information in a hurry. A name, a party size and often a phone number, typed at a host stand. It is Diner information like any other: use it to seat that party, do not add it to a marketing list (nobody standing at your door agreed to that), and do not keep it beyond what the day needed.
5. Marketing to Diners
5.1 Whether your booking page asks a Diner about marketing is your decision, made in your dashboard, and it is off until you make it. You choose between two styles, and they are not the same thing in law:
- Opt-in — an empty box. Nothing is assumed. This is consent under regulation 22(2) of the Privacy and Electronic Communications Regulations 2003, and it is the right answer if you are unsure.
- Soft opt-in — a box that starts ticked, which the Diner can clear. UK law permits this only in a narrow case: the address was obtained in the course of selling them a similar service, the marketing is your own, and an opt-out is offered both at the point of collection and in every message. It is a narrower basis than consent, not a way around it. If any of those three things stops being true, you may not rely on it.
5.2 We record which style you chose, the exact wording the Diner was shown, and when they agreed. That record is what answers a complaint, so do not ask us to change wording retrospectively — a new wording is a new version, going forward.
5.3 You may use what you collect to market your own Venue only, and only while it stands.
5.4 You must not:
- market to a Diner who has not agreed, or who has withdrawn;
- treat a booking as agreement — a Diner who was never asked has not said yes, and a phone booking taken without the question is not a "no" either;
- pass, sell, rent or otherwise disclose a Diner's details to another business for marketing, including another venue on this platform; or
- send marketing without a working and honoured unsubscribe link. Under soft opt-in this is not good practice, it is the basis itself.
5.5 Agreement is per venue. If you run more than one Venue, a Diner who agreed at one has not agreed at the others.
5.6 The export is a list of real people. Where the dashboard lets you download your opted-in Diners, that file is yours to protect: keep it somewhere access-controlled, do not email it around, delete copies you no longer need, and remember that a Diner's withdrawal has to reach the copies too. The dashboard's list is current; a spreadsheet on a laptop is a snapshot that goes stale the moment someone unsubscribes.
5.7 Complying with PECR in what you send is your responsibility. We record agreement; we do not send your marketing and we do not check it.
6. Cancellation fees
6.1 Every Cancellation Fee is a manual action taken by a person on your side against a card held through your own payment provider account. The Services do not charge anyone automatically, and we receive no part of any Cancellation Fee.
6.2 You must:
- have a cancellation policy that is clear, lawful and shown to the Diner before they confirm a booking;
- apply it consistently and only in the circumstances it describes;
- charge no more than the amount your policy states; and
- handle every Diner query, complaint, refund request and chargeback yourself.
6.3 You must not use the charging function punitively, arbitrarily, or in any way inconsistent with your published policy. Doing so is a material breach of the Terms of Service.
6.4 Your obligations to Diners as a trader under consumer protection law are yours alone. We provide the mechanism, not the policy.
7. Your booking page and venue content
7.1 The name, description, colours and content you configure appear on a page we host. Keep them accurate, lawful and not misleading.
7.2 Do not use the venue name field for marketing content. It appears in listings that prohibit it, and a name like "Best restaurant in town, Bob's" can have your listing rejected or removed.
7.3 Do not represent your Venue as being endorsed by, or connected to, us or any listing partner beyond the fact of using the Services.
8. Prohibited use
You must not, and must not permit anyone else to:
- attempt to access another venue's data, dashboard or records;
- attempt to bypass, disable or interfere with rate limits, the bot check, authentication or any other security measure;
- scrape, crawl or bulk-extract data from the Services by automated means;
- probe, scan or test the Services for vulnerabilities without our prior written consent;
- reverse engineer, decompile or attempt to derive the source code of the Services;
- introduce malicious code, or use the Services to send spam or unlawful communications;
- place unreasonable load on the Services, including repeated polling beyond what the work requires;
- create bookings that are not genuine, including to block a competitor or to manipulate availability;
- resell, sublicense or make the Services available to any third party; or
- use the Services for any unlawful purpose.
9. Reporting a security concern
9.1 If you discover or suspect a vulnerability, a data exposure, or misuse of an account or key, tell us immediately at hello@thezi.app.
9.2 Do not publish or share details of a suspected vulnerability with anyone else before giving us a reasonable opportunity to address it.
9.3 Report a suspected personal data breach to us as soon as you become aware of it, so that we can meet the 24 hour notification timeline in the Data Processing Agreement.
10. Breach of this policy
10.1 If you breach this policy we may suspend your access, in whole or in part, immediately and without notice where the breach is serious or ongoing, or on notice where it is not.
10.2 Serious or repeated breach is a material breach of the Terms of Service and we may terminate under clause 6.4 of those terms.
10.3 Suspension does not relieve you of the obligation to pay the Fee.
10.4 Termination and its consequences are governed by clause 6 of the Terms of Service, not by this policy.
11. Changes
We may update this policy on 30 days' written notice, in line with clause 15.2 of the Terms of Service.
Issued by Datatreehaus.