Adola Meet is the scheduling product run by Adola at meet.adola.co.uk. This policy explains what data we hold about people who sign in with Google to host bookings, and what data we hold about invitees who book a meeting through a public link. For the policy that covers Adola the agency, the adola.co.uk website, and our client work, see the Adola privacy policy. If you have any questions, contact us at hello@adola.co.uk.
Who this applies to
Adola Meet has two kinds of user:
- Hosts — Adola team members who sign in with their Google account to publish event types and accept bookings.
- Invitees — anyone who books a slot through a host's public link. Invitees do not create an account; they enter a name and email at booking time.
Data we collect from hosts
When a host signs in with Google, we ask for two Google Calendar permissions plus the standard sign-in details:
- See and download any calendar you can access using your Google Calendar (
calendar.readonly). We use this only to read free/busy windows so the public booking page can grey out times when the host is already busy. - View and edit events on all your calendars (
calendar.events). We use this to create the booking event on the host's primary calendar with the invitee as an attendee and a Google Meet link, and to update or delete that event when a booking is rescheduled or cancelled. We never list, read, or modify any event other than the ones Adola Meet itself created. - Email address, basic profile, and a Google account ID (
openid,email,profile). We use these to identify the host across sessions and to display the host's name and avatar on the booking page.
How tokens are stored
Google issues an access token (short-lived) and a refresh token (long-lived) when a host first connects. We store both tokens encrypted at rest in Supabase using AES-GCM with a 256-bit server-held key. Plaintext tokens are never written to disk and are only held in memory long enough to call the Google API. The encryption code is at lib/crypto.ts and the wiring is in lib/google/oauth.ts.
Access tokens auto-refresh every ~58 minutes when needed; refresh tokens persist until the host disconnects, deletes their Adola account, or revokes Adola Meet from their Google account.
Data we collect from invitees
When an invitee books a slot, we store the name, email address, and any answers to event-specific questions the host configured. We pass the email to Google when creating the calendar event so the invitee receives the calendar invite directly. We do not request any Google permissions from invitees and we never read an invitee's calendar.
What we do not do
- We do not sell or rent personal data.
- We do not use Google user data to train AI models.
- We do not read, list, or analyse calendar events that Adola Meet itself did not create.
- We do not share data with advertisers or analytics brokers.
Retention
Host tokens are retained until the host disconnects Google, deletes their Adola account, or revokes access from their Google account. Booking records are retained while the booking is active and for an audit period afterwards (we keep cancelled bookings to show "you cancelled this on date X"). On account deletion, all tokens are hard-deleted; booking records may be anonymised (replacing the host's name with "Deleted user") so that invitees retain a record of their own meeting history.
How to revoke access
A host can disconnect Adola Meet from Google at any time, in two ways:
- From inside Adola Meet — open settings, click "Disconnect Google". This clears the encrypted tokens from our database immediately.
- From your Google account — go to https://myaccount.google.com/permissions, find "Adola Meet", and click "Remove access". This revokes the tokens at Google and they stop working everywhere.
Either route is sufficient. The in-app disconnect is faster because it also clears our database row.
How to request deletion
Email hello@adola.co.uk and ask for account deletion. We will confirm by reply, then delete or anonymise the account within 30 days. Deletion is final.
Sub-processors
Adola Meet runs on these third-party services:
- Supabase — database and authentication (data stored in EU).
- Vercel — application hosting.
- Google Workspace — calendar and Meet (only the data the host has authorised us to access).
- Resend — transactional email delivery for booking confirmations.
- Cloudflare R2 — recording storage (only when a host uses the recording feature).
- Anthropic, Google, Groq — AI model providers used for transcription and summarisation, only on data the host explicitly uploads.
All sub-processors are bound by contract to use the data only for the service they provide.
Changes to this policy
We will update the "Last updated" date at the top of this page when this policy changes. Material changes will be notified by email to active hosts.
Contact
Questions about this policy or about your data: hello@adola.co.uk.
