Who else sees data

Every third party that can see personal data held by this service, what they see, and why. An unnamed subprocessor is data shared without disclosure, whatever the intention, so this list is published.

What enforces the mail list, and on which build — because this page is served by both. On the self-hosted Node build, the list is a runtime control: the service will not send mail through an SMTP host that is not on it, and says so loudly at startup. It keeps running and the booking still completes; only the message waits. On the Cloudflare Workers build, which is what runs the hosted service at booking.pumasi.ai, nothing checks that list at runtime — Workers cannot open SMTP connections at all, so that build sends through the Gmail API and never constructs the transport the check guards. What controls the Workers path is which transport the build itself constructs, a code change visible in review and in history, together with the disclosure below. That is a weaker control than the self-hosted build has, and it is named as weaker here rather than described in words that borrow the stronger one's credit.

In use now

• Cloudflare, Inc. — hosting, compute and the database. Sees everything the service stores, because it runs the machine and the storage: accounts, bookings, bookers' names and addresses, and the encrypted calendar credentials. It also processes connection data, including IP addresses, to deliver each request. Why: it is the platform the service runs on. Where: its global network; each customer organisation's data sits in its own isolated database.
• Google LLC (Gmail API) — sends every message the service sends: confirmations, sign-in links, reminders, cancellations. Sees the recipient's address, their name, the meeting time, and the text of any workflow message you write, because those are in the message. Why: there is no way to send a confirmation without the sender of it seeing the confirmation.
• Google LLC (Google Calendar) — only if an account holder connects a Google calendar. Reads the start and end of busy periods; with the separate write permission, receives the bookings it creates, whose title carries the booker's name and whose description carries their address. Why: to stop the service offering times you are not free, and to put the meeting where you already look.
• Microsoft Corporation (Microsoft Graph) — the same, for an account holder who connects Microsoft 365 or Outlook instead.
• Zoom Video Communications, Inc. — only on a booking for an event type whose location is set to Zoom. Receives the meeting title, which carries the booker's name; the agenda line, which carries the booker's name and their email address; and the start time, the duration and the account holder's timezone. Why: to mint a fresh meeting room for each booking rather than publish a standing personal room. Nothing is sent for an event type with any other location.
• Google LLC and Microsoft Corporation (sign-in) — only if an account holder chooses "Continue with Google" or "Continue with Microsoft" rather than an emailed sign-in link. The provider learns that that address signed in here, and returns the address to us. The request asks for the sign-in scopes only: it reads no calendar and no mailbox, and it is separate from the calendar grants above. Why: so that signing in does not need another account. An organisation may instead point the service at its own OIDC provider, which is a party that organisation chooses and runs, not one this service picks.

Whose authorisation the Zoom call is made on, and when nothing is sent at all. There are two routes and they are not the same disclosure. The first is the account holder's own connection: they press "Connect with Zoom", and the meeting is created with that account holder's token, on their authority, for a booking on their own event type. The second is a server-to-server credential belonging to whoever runs the deployment; it is tried only when the first route produces nothing, and it fires on the operator's authorisation rather than the account holder's — so on an event type set to Zoom, a booking can reach Zoom even though that account holder never connected anything. If neither route has a credential configured, no request leaves the service. At connect time Zoom receives no booker's data: the service asks Zoom only for the connecting account's own profile, and stores the address, display name and personal meeting room it returns.

Contacted, but sent no personal data

• date.nager.at — public-holiday dates, requested only when an account holder presses "block holidays". It receives a country code and a year, and nothing about any person.

What a hosting provider necessarily sees

Whoever runs the machine can read the database on it. That is true of every hosted service and is not special to this one; it is stated because a subprocessor list that omits the host is not a list of who sees the data. Self-hosting removes it entirely, which is why the project keeps self-hosting first-class: the software is open source and you may run your own copy.

Adding one

A provider is added by editing the published register and the code that enforces it together, in a change anyone can read. Account holders are told before an addition takes effect, and may object under the data processing terms.