Privacy

Calen is a scheduling and payment tool. Two kinds of people show up in it: hosts, who have an account and publish a page, and the people who book or pay them, who do not need an account at all.

A host decides what their page says and who they meet. For the bookings on it, they are responsible for the information their clients give them; Calen holds it on their behalf.

If you have an account: your name, your email address, a password (stored only as a hash, never as text), your time zone, which is first read from your browser, and whatever you choose to add — a photograph; the public address, display name, headline, description, website link and colour of your page; and what you set up to be booked: event types with their titles, descriptions, prices and where they take place (a meeting link, a phone number or an address, if you enter one), your working hours, and any discount codes. To be paid, a host also gives us bank details: the account holder’s name, IBAN, bank name, SWIFT/BIC code and postal address. We also record when you last signed in, which emails you have switched off, and for a host which monthly statements were issued, when, the totals each showed on that day, and whether the email about it went.

If you book a time: your name, email address, time zone, optionally a phone number, and anything you type in the notes box. The booking itself — what, when, how long, and what it cost — is kept with it.

If you pay: your name, email address and the country you are paying from, the amount, the currency, and what you wrote the payment was for. Card numbers never reach us: the payment happens on the provider’s own page. What the provider sends back about the payment we keep as it arrived: their reference for it, the amount, whether it succeeded, and whatever it says about the payer, which can include the name and billing address given at checkout and, for a card, its brand and last four digits.

Administrative records: when an account or a setting is changed, we log who did it, what changed, when, and the IP address the request came from.

Only the services needed to actually do the job, and only what each one needs:

• Payment providers — Stripe or PayPal. They receive the amount, the currency, our own reference for the payment and the booking, the page to return to, and a one-line description naming the host and, for a booking, the session; Stripe also receives the payer’s email address, for its checkout page and any receipt it sends. When a PayPal payment is refunded, the reason given for the refund goes to PayPal as a note to the payer. They do not receive the phone number, the notes on a booking, or what somebody wrote a payment was for.
• Mailgun sends the email — confirmations, reminders, cancellations and receipts, and account mail such as verification and password links, payout notices and a host’s monthly statement. It handles the message, which means the addresses and content of that message, including any calendar attachment. A statement email carries that host’s totals for the month and names nobody who paid them.
• Google, if a host connects their calendar. Bookings are written into that calendar with the attendee as a guest, which means the attendee’s name, email and notes go with them, and Google sends the attendee the invitation, and any later change or cancellation, from the host’s Google account. Reading the calendar back only takes the times that are busy; the titles of a host’s other events are discarded and never stored. A host can disconnect this at any time, and revoke it from their Google account.
• Google reCAPTCHA, on the sign-up and password-reset forms only, to keep robots out.
• Google, for one picture. A host who signed up with Google and has not uploaded a photograph of their own shows their Google profile picture, which your browser loads from Google’s servers when you open that host’s page. Google sees that request — your IP address and browser — and nothing you type.

There is no analytics, no advertising and no tracking script anywhere on this site, and the only third party that can set a cookie here is Google reCAPTCHA, on those two forms. Nothing is sold, and nothing is shared for marketing.

Connecting a Google account is optional, and a host who never connects one can use all of Calen. This section is about what happens to what Google gives us when they do.

What we access. Signing in with Google gives us the name, email address and profile picture on that account, and asks in the same step for the calendar permission. Connecting a calendar, there or under Settings, gives us that account’s email address and access to its calendar events — we use the primary calendar and no other — and nothing further: not the ability to create or delete calendars, not their sharing settings, and no other Google service.

How we use it. The name, address and picture identify the account and fill in the host’s public page so they are not asked for them twice; the address is also where confirmations and receipts are sent, and it is given to the people who book that host: replies to their confirmation go to it, and the calendar file names it as the organiser. Calendar events are read so the booking page can leave out times the host’s calendar shows as busy — and only the start and end time of each timed event is kept for it; events marked free, declined or cancelled, and all-day ones, are left out. Titles, descriptions, locations and guest lists are discarded as they arrive, and are never stored, logged, or sent anywhere. The same access writes each confirmed booking into the host’s calendar, with a Google Meet link when it is a video call that has no link of its own, and adds the person who booked as a guest, so Google sends them the invitation, and later any change of time or the cancellation, from the host’s connected Google account, whose address they see as the organiser. It moves that entry when a booking is rescheduled, and removes it when one is cancelled. Calen only ever changes or deletes entries it created itself.

What we keep, and for how long. An account first created by signing in with Google keeps the name and a link to the profile picture as its own details until the host replaces them, and the email address for as long as the account exists; erasing the account removes all three. Later sign-ins use the address to find the account and copy nothing else. An account that signs in with Google also carries a record saying so, and no token is stored with it: the only Google tokens in our database are the calendar connection’s. Until 6 October 2026 the tokens from signing in were stored as well; they have been deleted from the database, and backups made before that change went live still hold them until those backups are themselves deleted, a little over a week later. While a calendar is connected we hold the Google account’s email address, so the host can see which account they connected; the access and refresh tokens, encrypted; a list of busy start and end times, which is read again from Google whenever the booking page needs it and the list is more than five minutes old, and is not a copy of anything else; and, against each booking, the identifier of the calendar entry we created, so that entry can be moved or removed later, and the Meet link if Google made one. The address, the tokens and the busy times are kept until the calendar is disconnected under Settings or the account is erased; revoking access at Google makes the tokens useless but does not by itself delete our copies. The identifier and the link stay with the booking.

How it is deleted. Disconnecting the calendar under Settings deletes the tokens, the connected address and the cached busy times straight away; signing in with Google afterwards asks for the permission again, and granting it connects the calendar again. Erasing the account deletes the same things, and with them the name, the address, the picture link and the record of signing in with Google. Erasing asks for the account’s password, so an account that has only ever signed in with Google sets one first, through Forgot password on the sign-in page. Access can also be revoked from the host’s own Google account page, which ends it at Google’s end as well; on its own that deletes nothing we hold, so disconnect here too. Calendar entries already written into a host’s calendar are left alone — they are the host’s, and deleting them would strike out meetings people are expecting to attend.

What we never do. Google user data is not sold, not used for advertising, not used to train any artificial-intelligence or machine-learning model, and not transferred to anyone else, except as needed to provide the features described on this page or where the law requires it. Calen’s use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements.

A few of our own, all of them to do with signing in. Two are set when you first open the site: a random token that protects the sign-in form against forged requests, and a note of which page to send you back to. A third keeps you signed in once you are, and short-lived ones carry you through signing in with Google or connecting a calendar. Preferences such as the light or dark theme are kept in your browser’s own storage rather than in a cookie. The one cookie that is not ours is Google reCAPTCHA’s, which Google may set on the sign-up and password-reset forms. There are no analytics or advertising cookies, so there is no cookie banner to dismiss.

Bookings and payment records are kept, and stay when the account they belong to is erased. They are the record of what was agreed and what was charged, and a cancelled booking is kept for the same reason — so both sides can still see what happened. A host’s monthly statement is worked out from those payments, refunds and payouts each time it is opened, so it lasts exactly as long as they do. The one thing kept beside them is the note that a month was issued, with its totals as they stood, which is what lets the statement say when a month has changed since.

Database backups are kept for about a week and then deleted automatically. A backup made before something was deleted still contains it until that backup is itself deleted.

A host can erase their own account under Settings, without asking anyone. Name, email address, photograph, password, bank details and every session go, the public page is taken down, and working hours and discount codes are deleted with it, along with the note of which emails were switched off and which statements were issued, totals included. Statements are opened through the account, so the host cannot open them afterwards. They are worked out from the payments, refunds and payouts that are kept, so the staff who pay hosts still can — to settle a balance still owed, for instance. Event types are hidden and kept, not deleted, because the bookings that stay point at them. Bookings and payments the host took stay, with the host’s name removed, and so do their payouts — those they asked for and those recorded against a statement — with the bank details recorded on each: they record what was agreed, what was charged and where the money was sent, they concern the other party as well, and a tax authority or a card issuer can ask about them for years. The administrative log of changes to the account stays as well — what changed, when, and the IP address the request came from — under the account’s number, without the name or the address. The screen lists what goes and what stays before anything happens.

Bookings you made with other hosts, and payments you made to them, keep what you gave at the time — your name and email address, your time zone, and any phone number, country or note: they are those hosts’ records. Ask us if you want them removed.

A connected Google calendar — its tokens, the connected address and the cached busy times — is deleted when it is disconnected, and again as part of erasing an account. See Google user data above.

The site is served over HTTPS. Passwords are stored as bcrypt hashes, which cannot be turned back into the password, and changing or resetting a password ends every other session on the account. The Google calendar tokens described above are encrypted with AES-256-GCM and are never returned by any part of the site.

A copy of what we hold about you, a correction, or deletion. If you are in the UK or the EU you have these rights under the GDPR, and you may also complain to your data protection authority. Ask us first — it is usually quicker.

If you booked with a host, they hold that booking too. We will pass your request on to them where it concerns their records.

Write to support@calen.nl.