Privacy Policy

1. Who controls your data

Slotora online booking software is operated by Belavin Limited, (company no. 16735157), 6 Salstar Close, Birmingham, B6 4PP, United Kingdom. For privacy matters contact hello@slotora.io. We are registered with the UK ICO (registration 00014129250).

2. Two roles

For your own account and our marketing, Slotora is the data controller. For your clients' booking data (what your customers submit on your booking page), YOUR business is the controller and Slotora is a processor acting on your instructions — governed by the data-processing section of our Terms.

3. What we collect

• Account data: name, email, password (hashed), role.
• Business data: business name and registered legal name, trading address, VAT or tax number and the result of any check we make on it, services, prices, working hours, images, and the identity and bank details your payment provider collects when you open a connected account (those go to the provider, not to us).
• Booking/client data: the guest's name, email, phone, appointment details and intake-form answers.
• Health and consultation data, where your business asks for it: allergies, sensitivities, medication and similar answers on an intake or consultation form, and the signature a client draws on a consent or waiver form. This is special-category data under Article 9 GDPR. Your business decides whether to ask for it and on which Article 9(2) condition it relies — normally the client's explicit consent, given on the form itself; Slotora only stores and displays it on your instructions.
• Technical data: logs, device/browser info; on the marketing site, cookieless anonymous visit counting (a daily-salted hash, not personally identifying).
• Mobile app: if you enable notifications, a push registration token plus your device platform and language, stored against your account and deleted when you sign out, uninstall, or delete your account.

3a. The mobile app

The Slotora app for iOS and Android shows the same admin as the website. It asks for camera and photo-library access only when you attach an image yourself (portfolio, before/after, logo) — nothing is captured in the background, and we never scan your library. It contains no advertising identifiers, no analytics SDK and no tracking of any kind, and we do not share app data with data brokers. Notification permission is optional; declining it changes nothing else in the app.

3b. Google Calendar (Google user data)

Connecting a Google Calendar is optional and stays off until a team member switches it on for her own account. It is done per person: nobody can connect somebody else's calendar, and a salon owner cannot connect a stylist's private diary. Where nobody has connected one — which is the case on every account until somebody does — none of what follows happens at all. Calendars at other providers — Apple iCloud, other CalDAV services and Microsoft 365 — are covered in section 3e, not here. What follows describes, in full, everything Slotora does with data it obtains through Google APIs. We ask for the narrowest permissions this feature can work with. There are four, and these are all of them:

• Your free/busy times (calendar.freebusy): the start and end of the periods your own calendar already shows you as busy. This is the only permission by which Slotora sees anything at all about your own calendar, and what Google returns for it is a list of intervals. Titles, descriptions, locations and guest lists are not part of that answer — Slotora is never sent them, because this permission does not return them. We read your main Google calendar.
• A Slotora calendar inside your Google account (calendar.app.created): we create one extra calendar of our own and write your Slotora bookings into it, so you see them alongside the rest of your day. This permission reaches only the calendar we created; it cannot see or change any other calendar you own. It also lets us read that one calendar back, which is how we notice when one of our own entries has been edited or deleted in Google and put it right.
• Which Google account you connected (openid and userinfo.email): the email address of the account you sign in with, so the screen can show you which account is connected. Somebody with three Google addresses needs to see which one Slotora is using, and to notice if a reconnection attached a different one. It is not used to contact you — Slotora already has your own address for that.
• What we deliberately do not ask for: permission to read the events in your own calendars, and permission to list your calendars. Both would tell us more than blocking an hour requires, and we have asked for neither. The cost of that choice is real and we accept it: your Slotora diary shows an outside commitment as busy time, not by name.

3c. What Slotora stores from Google, for how long, and how to disconnect

Two things are stored, and nothing else.

• The connection: the Google account address you signed in with, the identifiers of the two calendars involved — your main Google calendar, which is the one we read, and the Slotora calendar we created — and the access and refresh tokens Google issued. The tokens are encrypted with AES-256-GCM before they reach our database, they are shown nowhere in the interface, and they are deliberately left out of the data export — an access key is not a record of yours to download, and an export file is the easiest thing in the product to lose.
• Busy blocks: for each period that should make you unbookable, a start time and an end time. That is the whole row. It carries no title and not even an identifier of the entry behind it, because what Google sends us is an interval with no identity, and blocking an hour does not require knowing what the hour is for.
• Both live exactly as long as the connection does. Disconnect it and Slotora does not merely forget the token: it revokes it at Google, deletes every busy block that connection created, and deletes the connection record itself — at once, not on some retention schedule. The same happens by itself if you are removed from the team, or if the business deletes its account.
• You can disconnect from the connected calendar in your Slotora settings, and you can revoke Slotora's access independently at any time in your Google account's security settings, at myaccount.google.com/permissions. If you revoke it there, the next sync fails, we mark the connection as disconnected, stop trying, and tell you.

3d. What Slotora never does with Google user data

Google Calendar data is used for one purpose: so that your true availability shows in Slotora, and so that your Slotora bookings are visible in your own calendar. For nothing else — and the same holds for the calendars in section 3e. Specifically:

• We do not sell it, rent it out, or pass it to a data broker.
• We do not use it for advertising — ours or anyone else's — and we build no profiles, audiences or segments from it.
• We do not send it to Gemini or to any other AI feature in Slotora, and we do not use it to develop, train, improve or evaluate any artificial-intelligence or machine-learning model, ours or anyone else's.
• We do not read your calendar entries — and the precise version of that is worth more to you than the short one. Google never sends us the title, description, location or guests of anything in your own calendar; the permission we hold does not return them. There is exactly one calendar whose entries Slotora does read: the Slotora calendar we created inside your account, where we read back the entries we wrote there ourselves, so that we notice if one of them was changed or deleted in Google. Those are our own booking entries, holding what we put in them; the check runs in memory and nothing from it is stored.
• No Slotora employee looks at your Google Calendar data, other than in the narrow cases Google's own policy permits: where you have asked us to in order to fix something, where security requires it, or where the law compels it.
• We do not pass it to the processors listed in section 6. It is held on the database and application hosting the whole service runs on — Neon and Netlify — and it goes nowhere else.
• Slotora's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

3e. Other calendars: Apple iCloud, other CalDAV services and Microsoft 365

A team member can connect a calendar at another provider instead of, or as well as, a Google one. It is optional, done per person in the same way as 3b describes, and where nobody has connected one none of what follows happens. The account is hers, under her own agreement with its provider; we do not engage Apple, her CalDAV provider or Microsoft to process anything on our behalf. This section describes, in full, what Slotora does with the data these connections bring.

• Apple iCloud (the calendar on an iPhone) and other CalDAV services. Apple offers other apps no sign-in for calendars, so you create an app-specific password at account.apple.com and enter it in Slotora together with your Apple Account email address; another CalDAV service (Fastmail, Nextcloud and the like) connects the same way, at an address you give. The app-specific password is not your Apple Account password. You can revoke it at account.apple.com at any time, and Apple revokes every app-specific password when your Apple Account password changes.
• What these servers send us, and what we keep. Unlike Google, a CalDAV server sends Slotora the events themselves from the calendars it reads — including their titles, descriptions, guests and locations. Slotora reads every calendar in the account except the Slotora calendar, uses the events in memory to work out when you are busy, and stores only the start and end time of each busy period. The events, and their titles, descriptions, guests and locations, are not stored. This is the one real difference from 3b and 3d: with Google we are never sent what your events are called; with iCloud and CalDAV we are sent it and do not keep it.
• What we write into your calendar. We create one calendar named Slotora in your account and write your Slotora bookings into it: the client's name and the service, the salon's name and the booking's note, and the salon's address — never the client's phone number. We write to no other calendar, and we read the Slotora calendar back to keep it in step with Slotora.
• Microsoft 365 and Outlook.com, once Slotora offers this connection (it is not switched on yet). You sign in at Microsoft and allow five permissions: offline_access (so the connection lasts without signing in again), openid, email and User.Read (so the screen can show which account is connected), and Calendars.ReadWrite (the only Microsoft permission that lets an app create its own calendar; Microsoft has no narrower one). That permission would allow more than we use: Slotora asks Microsoft for five fields of each event only — start, end, whether it shows you as busy, whether it is all-day and whether it is cancelled — so titles, guests and locations never reach us, and it writes only to the Slotora calendar it created, with the same entries as above. You can withdraw Slotora's access at any time by removing it from the apps in your Microsoft account.
• What is stored, and for how long. The connection: your account's email address, the address of your calendar service, which calendars are read and which one is Slotora's, and the app-specific password (iCloud and CalDAV) or Microsoft's access and refresh tokens, encrypted with AES-256-GCM before they reach our database and never shown in the interface. And the busy periods, as start and end times with nothing else on them. Both live exactly as long as the connection: disconnect it and Slotora deletes the password or tokens, the connection record and every busy period it created, at once; the same happens if the business deletes its account. If the provider refuses the password or permission for good, Slotora stops, deletes the busy periods and tells you. Entries already written into your calendar stay there — they are yours, and deleting from your account on the way out is a write you did not ask for.
• The promises of 3d apply to this data as well: we do not sell it, rent it out or pass it to a data broker; we do not use it for advertising or build profiles, audiences or segments from it; we do not send it to Gemini or any other AI feature, or use it to develop, train, improve or evaluate any artificial-intelligence or machine-learning model; no Slotora employee looks at it except where you have asked us to fix something, where security requires it or where the law compels it; and it is held on the database and application hosting the whole service runs on — Neon and Netlify — and goes nowhere else.

4. Legal bases

• Performance of a contract (Art. 6(1)(b)): running your account and bookings.
• Legitimate interests (Art. 6(1)(f)): service security, improvement, abuse prevention.
• Legal obligation (Art. 6(1)(c)): e.g. accounting duties for paid plans.
• Consent (Art. 6(1)(a)): where we ask for it (e.g. non-essential communications).

5. How we use it

Solely to run the service: showing availability, creating bookings, and sending transactional emails (confirmations, reminders, cancellations, waitlist notices). We do not sell data and we do not run third-party advertising trackers.

6. Recipients and processors

We keep data confidential; our sub-processors are: Neon (database hosting, EU/London), Netlify (application hosting/CDN), Resend (transactional email), BulkGate (text messages, only if you switch SMS on), Twilio (the inbound number your clients can reply to, the fallback route when a text cannot go out through BulkGate, and the telephone line the AI receptionist answers on), Retell AI (the AI phone receptionist — where a business switches it on, Retell answers the phone in that business's name, so it processes the voice of anyone who rings, including people who have never opened a Slotora page; it returns a written summary of the call and we never keep a recording; the caller's number is removed from the call record after 90 days and the record itself after a year), Google Firebase (mobile push notifications), Google (Gemini AI — only for the optional AI features you trigger yourself, and never used to train their models), and Stripe (payments — used whenever a business takes card payments from its clients through Slotora, and separately if that business subscribes to a paid plan). Each processes data under a data-processing agreement — in most cases the provider's standard terms, accepted when the account was opened — and only as needed to run the service. Further recipients are engaged by the business rather than by us, on its own account and under its own contract with them, and receive nothing until it connects them: Meta (Facebook, Instagram and WhatsApp — a WhatsApp reminder carries the client's name and number), an invoicing provider (Számlázz.hu, Billingo, Xero or QuickBooks — an invoice carries the client's name and billing address), Google (Google Calendar — only where a team member connects her own Google account; the entries Slotora writes into her calendar name the client and the service booked, and sections 3b to 3d set out the whole of it), Apple or another calendar service (iCloud Calendar or another CalDAV service — only where a team member connects her own calendar with a password she creates for Slotora; it receives the same booking entries, and section 3e sets out the whole of it), and Microsoft (Outlook / Microsoft 365 calendar — only once Slotora offers that connection, and only where a team member connects her own Microsoft account; section 3e).

7. International transfers

Data is primarily stored in the EU/EEA and the United Kingdom. Where a transfer occurs, it is protected by an adequacy decision or the European Commission's Standard Contractual Clauses (and the UK IDTA).

8. Retention and deletion

Data is retained while an account is active. Request deletion at hello@slotora.io; we action requests within 30 days. What the law requires us to keep, we keep for exactly as long as it says and no longer: the record of what we sold you — the supply, the country and how it was taxed — is kept for six years from the end of the financial year of the transaction, which is what UK tax records require. Deleting your account does not delete those figures, but it does take your identity out of them everywhere the record does not need it. There is one exception: an EU sale, where we charge no VAT because you account for it yourself under the reverse charge — your VAT number and the legal name on the invoice are the evidence for why none was charged, so they are kept for the same period. If you tick “Let me know when this is fixed” when you delete your account, we keep your email address for that single purpose: to tell you once that the issue you raised has been addressed. We delete it within 30 days of that one message, and in any case no later than 12 months after you ticked the box; you can ask us to delete it sooner at hello@slotora.io.

9. Your rights

• Access, rectification, erasure, restriction, portability and objection.
• Withdraw consent at any time (without affecting prior lawful processing).
• Complain to a supervisory authority: the ICO (ico.org.uk) in the UK, the NAIH (naih.hu) in Hungary, the UODO (uodo.gov.pl) in Poland, or the ANSPDCP (dataprotection.ro) in Romania.

10. Cookies

Strictly necessary cookies — your login session and language preference — always work, plus one short-lived cookie that measures our own marketing (a salon referral code). Beyond those, the bar at the foot of the page asks two separate questions. “Analytics only” loads Google Analytics and nothing else. “Accept all” additionally allows a Meta advertising pixel on our marketing site and lets Google’s tag store advertising identifiers, which is how we tell which of our adverts brought a salon that actually signed up. Decline, or simply ignore the bar, and none of it loads. None of it runs on a salon’s own booking page. See our Cookie Policy for detail. Where the Meta pixel is allowed and you create an account, your name and email address go to Meta scrambled (hashed) and never as readable text, purely so it can recognise that the sign-up came from an advert.

11. Children

The service is for businesses, not for under-16s. We do not knowingly collect data from children.

12. Security

Encrypted transport (HTTPS), password hashing, access controls and regular backups protect your data.

13. Requests from public authorities

If a public authority asks us to disclose personal data, we first check whether the request is lawful and binding on us, and we challenge requests we consider unlawful or overbroad. We disclose only the minimum the request actually requires — never a whole account or database because a single record was asked for. We document every such request, our response, the legal reasoning and who was involved. We notify the controller concerned unless the law forbids it.

14. Changes

We may update this policy; we will notify you of material changes. Last updated: 27 August 2026.