Data Processing Agreement

1. Scope and roles

This agreement applies between you (“Controller”), the holder of a CalFree account, and CalFree (“Processor”), which runs the service at calfree.dev. It supplements the terms of service and takes precedence over them on the subject of processing personal data.

For your own account details — your name, email and settings — we are the controller, and the privacy policy governs that.

It is accepted when you create an account. No signature is needed; if your organisation requires a countersigned copy, write to us.

2. Processing instructions

We process personal data only to provide the service: calculating open times, creating, changing and cancelling bookings, sending the emails a booking generates, and syncing the host’s calendar where connected. Using the REST API or the MCP server is a documented part of the service, not separate processing.

We will not process it for any other purpose, and in particular we do not sell it, use it for advertising, or use it to train machine learning models. If we are legally compelled to disclose data we will tell you first, unless the law forbids it.

3. Duration

Processing lasts as long as your account does. It ends when you delete your account, or when either side ends the terms of service.

4. Confidentiality

Anyone with access to personal data on our side is bound by confidentiality, and access is limited to those who need it to operate and support the service.

5. Security measures

These are the measures we apply:

• Encryption in transit. HTTPS throughout, with HSTS in production.
• Encryption of credentials at rest. Calendar refresh tokens are encrypted with AES-256-GCM before storage, with the key held outside the database.
• Hashed secrets. API keys and the tokens behind invitee reschedule and cancel links are stored only as SHA-256 hashes, never in plaintext. A revoked key fails on the very next request.
• Isolation of tenants. Every query is scoped to the authenticated host, and an API key reaches only its owner’s data.
• Abuse limits. Public requests, booking attempts and API calls are rate limited per client and per key. Optional email verification makes an invitee prove ownership of their address before a booking completes.
• Browser hardening. Responses set X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, X-Frame-Options: SAMEORIGIN, Cross-Origin-Opener-Policy: same-origin and a permissions policy denying camera, microphone, geolocation, payment and USB. Cross-origin API access is denied unless we allow-list an origin.
• Data minimisation. Account exports deliberately exclude key hashes and calendar tokens, because an export file ends up in places nobody controls.

No Content-Security-Policy header is set yet, and we do not claim measures beyond those listed here.

6. Sub-processors

You give general authorisation for the sub-processors in Annex 2. We will tell account holders by email before adding or replacing one, in time for you to object; if you object, you may delete your account and export your data.

7. International transfers

The application and database run on servers in Bangalore, India. Some sub-processors, such as email, calendar and payment providers, may process data in other countries, including the United States. Where a transfer needs a safeguard, it relies on an adequacy decision or on Standard Contractual Clauses, as set out in that provider’s own terms. Annex 2 names the providers so you can check.

8. Helping you meet your obligations

Rather than route these through a support queue, the service implements them directly:

• Access and portability. Settings → Your data exports your account, event types, availability and every booking with its answers, as JSON.
• Erasure. Deleting a booking removes that invitee’s data. Deleting your account removes all of it.
• Rectification. Bookings and event types are editable in the dashboard and over the API.
• Objection and restriction. Blocking an email address stops that person booking you at all.

If an invitee contacts us directly about data you control, we will refer them to you rather than act on it ourselves, and tell you about it.

9. Personal data breach

We will notify you without undue delay, and in any case within 72 hours of becoming aware of a personal data breach affecting your data, with what we know about its nature, the categories and rough number of people affected, the likely consequences and the steps taken. We will keep you updated as more becomes known.

10. Audit

On reasonable written request, and no more than once a year, we will answer a security questionnaire and provide what documentation we hold.

11. Return and deletion

On termination, data is deleted rather than returned, because you can export it yourself at any time beforehand. Deletion cancels upcoming meetings so invitees are told, revokes calendar access at the provider, and removes email records, stored API responses and the account with everything attached. Residual copies may persist in encrypted backups until those expire: nightly backups are kept for 30 days and one a month for about 13 months.

Annex 1 — What is processed

Categories of people

• Invitees: people who book a meeting with you.
• Attendees of a group session.
• People who vote in a meeting poll, and people who fill in a routing form.

Categories of data

• Identity and contact: name, email address.
• Context: time zone, the meeting time chosen, and which channel booked it (page, API or agent over MCP).
• Content you asked for: answers to your booking questions or routing form, the times a poll voter can make, and a cancellation reason if given.
• Technical: a hash of the token in their manage links, an idempotency key when one was used, and the IP address used for rate limiting.

No special category data is processed by design. If your booking questions ask for any — health information, for example — that is your decision as controller, and your lawful basis to establish.

Purpose

Arranging, confirming, reminding about, rescheduling and cancelling meetings between you and your invitees.

Annex 2 — Sub-processors

These are the companies that may handle your invitees’ data. Where a row says “only when”, nothing reaches that company unless you turn the feature on.

Contact

[email protected].