Calemander

Security and data handling

Last reviewed 23 September 2026.

The short version: we never see a card number, each workspace's data sits in its own database rather than a shared table, and you can take your bookings and contacts out on any plan. What follows is the longer version, including what we do not claim.

If you have found a security problem, the page you want is reporting a vulnerability, which carries our severity definitions, patch timelines and safe-harbour commitment.

We never store card numbers

Card numbers are entered in the payment provider's own fields and never reach Calemander; we store the payment status and the provider's reference identifiers. That is true of a card held on file too — what is saved is a token at the provider, not a number here.

Money your clients pay you goes to your own account with the payment provider you connected. We do not hold it.

Each workspace has its own database

A workspace's scheduling data — event types, availability, bookings, contacts, the answers your clients give — lives in a per-workspace database, not in shared tables separated by a customer column. One tenant's queries cannot reach another's rows, because they are not in the same place.

Everything runs on Cloudflare infrastructure and is encrypted at rest by the platform, with TLS in transit. Third-party credentials get a second layer of application-level encryption on top of that, so they are not readable from a database dump alone. What that means in detail is in encryption below.

Encryption

In transit. Every connection to Calemander is HTTPS, terminated by Cloudflare. There is no plain-HTTP listener to fall back to, on any hostname we serve, including a customer's own booking domain.

At rest, by the platform. Cloudflare encrypts what it stores for us — the per-workspace databases, the control-plane database, the key-value namespaces and the file storage. That layer is Cloudflare's and we did not build it.

At rest, by us, on top of that. Five kinds of credential get a second layer we control — AES-256-GCM with a 256-bit key that exists only as a worker secret, never in the codebase and never in a database: CalDAV app passwords, the Calendly token, the Square connection, the LawPay merchant secret key, and both halves of a Clio connection. For those five, a copy of the database on its own does not yield a usable credential. Google, Outlook and Zoom refresh tokens are stored as text in your own workspace's database, protected by Cloudflare's encryption at rest and the per-workspace isolation above, and by nothing further of ours.

Identifiers that only name something — a merchant id, a Clio region, a calendar id — stay unencrypted deliberately, so that a settings page or a webhook route never has to hold a decryption key to do its job.

What is stored

• Account data — your name, email, workspace name and the settings you configure.
• Scheduling data — event types, availability rules, bookings, and each invitee's name, email, optional phone number and answers to your booking questions.
• Calendar data — busy times and events for calendars you connect, used to avoid double-booking. We do not read or analyse the contents of your other events beyond their busy ranges, and never use calendar data for advertising.
• Integration credentials — OAuth tokens and keys for the services you connect yourself: Google, Microsoft, Zoom, Calendly, CalDAV calendars, Stripe, Square, LawPay and Clio, plus conferencing account identifiers.
• Billing data — subscription status, seat count, Stripe identifiers.
• Operational data — email delivery events, the webhook ledger, error logs.

Calemander does not store card numbers, meeting recordings, meeting content, participant lists, or chat and contacts from a conferencing provider.

Where data is processed

We do not offer a choice of region, and we are not going to claim your data stays in one country when it does not. Here is the actual picture.

• Your workspace database is a Cloudflare Durable Object. Cloudflare creates one in a data centre near the request that first opened it, so a workspace set up in the United States is stored in the United States in practice. We do not currently pin it to a jurisdiction. That is how it behaves today, and it is not a term you can hold us to.
• Routing data and caches sit in Cloudflare's key-value storage, which is replicated across Cloudflare's network by design and has no region setting.
• Email we send on your behalf goes out through Emailit, a provider established in the Czech Republic whose privacy policy commits to keeping personal data within the European Union. So a booking confirmation carries your client's name and email address through the EU, wherever you and they are. If your workspace sends from its own verified domain, the provider you verified it with carries it instead.
• Text reminders go through Telnyx, a United States company, when a host turns them on.
• Payments are processed by Stripe, Square or LawPay under your own account with them. Each publishes where it operates, and the card details never come to us at all.
• Calemander itself is operated from Chicago, in the United States, by a United States company. Support access to production happens from there.

Countries involved on the ordinary path, then: the United States and the Czech Republic, plus whichever Cloudflare data centre serves a given request. Providers you connect yourself add their own, and their own published lists are the authority on that. If your regulator, your bar association or your client requires data to stay in one jurisdiction, tell us at support@calemander.com before you sign up, because today we cannot promise it.

Who is responsible for what

For data about you, the host, Calemander is the controller. For data about the people who book you, your workspace is the controller and Calemander is the processor acting on your instructions. That matters in practice: if one of your clients asks us to delete their details, we route the request to you.

Support

Support for Calemander, including anything about a connected integration such as Clio, LawPay, Stripe, Square, Google or Zoom, is ours and reaches us at support@calemander.com. We do not redirect customers to a partner's support desk. Security reports go to the separate address on the vulnerability disclosure page.

Subprocessors

Calendar and conferencing providers — Google, Microsoft, Zoom, Apple and Fastmail over CalDAV, Calendly — are connected by your own authorization and act on your behalf rather than as our subprocessors.

Clio is in that second group. The distinction is worth stating plainly, because it decides who answers to whom. A subprocessor is a company we chose, that we instruct, and that we are answerable to you for. An integration party is a company you chose and already have your own agreement with; we hold the authorization you granted and write to it on your instruction, and you can revoke that authorization at your end or ours at any moment. Your Clio data is governed by your agreement with Clio, not by this page.

LawPay appears in the table above rather than here, alongside Stripe and Square. It is a payment provider you connect to your own merchant account, so it is an integration party in spirit — but money is the one place where listing more than strictly required is the right error to make, and the other two payment providers have always been listed.

If we add a provider that every workspace uses, we email workspace owners before it goes live and note the change on the privacy policy, where the full list lives with the data each provider handles.

Retention, export and deletion

• Export is on every plan. Bookings and contacts export to CSV from the dashboard, Free included. Nothing about leaving is behind a paywall.
• Bookings and scheduling data are kept for the life of the workspace, because hosts rely on their booking history.
• Intake answers can be set to expire. A workspace can choose to have the answers given on its booking forms deleted 30, 90 or 365 days after the appointment ends. It is off unless the workspace turns it on, and it deletes the answers along with the copies we hold of them — the booking's change history, the record the post-booking automation worked from, and any reference a requirement took from an answer. The questions remain, so the booking shows what was asked and the date its answers were deleted. Emails, text messages and calendar invitations already sent are not recalled, and deletion cannot be undone.
• Disconnecting an integration removes the connection and the tokens we hold for it, and so does deleting the account. Removing our app from the Zoom Marketplace sends us Zoom's deauthorization notice and we remove the stored credentials automatically; for every other provider, disconnecting in Calemander is what removes them.
• Email delivery events and the webhook ledger are kept for a rolling operational window.
• Billing records are kept as long as tax and accounting require. Account data is deleted on account deletion.
• Requests for access, correction, export or deletion go to support@calemander.com and are actioned within 30 days.

Access control

Access to production data is limited to the operator of the service, through credentialed tooling, and is used only for support and incident response. There is no standing administrative console that browses customer bookings; the operational dashboards we do keep see counts and internal identifiers, never names, email addresses or phone numbers.

The Cloudflare account that runs the service, its databases and its secrets, and the GitHub account that holds the source code, both require multi-factor authentication to sign in. We do not publish a claim about every other account we hold; the ones we have verified are the ones we name.

Production secrets live as encrypted platform secrets and are not readable from the codebase, from a deployed bundle, or from a development machine's source tree. The automated tooling used in development is explicitly prohibited from reading credential files, and that prohibition is written into the instructions those tools run under rather than left to habit.

Signing in to Calemander never involves a password, and the emailed one-time link keeps working whichever way you sign in. Passkeys are an optional alternative and are not enforced — nobody has to add one. A passkey is phishing-resistant: your device will only use it on calemander.com and your workspace's address, so a look-alike site cannot ask for it. We store only its public key, which cannot sign anyone in on its own, and we refuse a passkey sign-in unless your device confirmed it was you with a fingerprint, face or device PIN.

Inside your own workspace, a member is either an admin or a member. There is no finer permission model yet, so a member can see the workspace's bookings. If you need a role that can take bookings but not read the rest, we do not have one today.

Logging and monitoring

Every request writes one structured line — route, method, outcome, timing, the data centre that served it and the deployed version — kept for Cloudflare's default retention on this plan, which we have not extended. Longer-lived operational metrics are kept as counters for three months: request timing, message and email volume, workspace counts, integration failures.

Those records carry no personal data, on purpose. A recipient's email address never reaches them at all, and a phone number is reduced to its country calling code before it does. Where a record needs to name a workspace or a member it uses an opaque internal identifier. This is a deliberate constraint rather than an accident of design: these counters cannot be edited or deleted row by row, so anything personal written into one could not be taken out again.

Application error logs can contain a booking identifier or an error message returned by a provider. They are kept for the same short operational window and are not used for anything but fixing what went wrong.

Backups and recovery

We run no backup process of our own, and the honest reason is that Cloudflare's is better than one we would write. Every per-workspace database supports point-in-time recovery to any moment in the previous 30 days, and so does the control-plane database that maps hostnames to workspaces. Recovery is per workspace, so restoring one customer does not disturb anyone else.

What that does not give you is a copy of your data in your own hands, which is a different need and one you should not depend on us for. Bookings and contacts export to CSV from the dashboard on every plan, including the free one, and exporting regularly is a reasonable thing to do.

The service itself has no failover to a second provider. If Cloudflare is down, Calemander is down, and we would rather say that than imply a resilience we have not built.

Incident response

A suspected incident is triaged immediately: scope established, affected credentials rotated, the vulnerability fixed and deployed, and affected customers notified where their data may have been exposed. Where a fix will take longer than the exposure can be tolerated, the affected feature is turned off first and repaired afterwards.

Notification. When we confirm that customer data was exposed, we email the affected workspace owners without undue delay, and within any period a law we are subject to requires, with what we know at that point rather than waiting for a complete account. The notice says what was reachable, for how long, whether we can tell if anyone reached it, and what we have done. Where the people who book you are affected, you hold that relationship and we give you what you need to tell them.

To report a vulnerability, please use the disclosure process, which sets out scope, severity definitions, patch timelines and our safe-harbour commitment. Anything else goes to support@calemander.com.

What we do not claim

Plenty of pages like this one imply more than the company has done, so here is the rest of it plainly. Calemander does not hold a SOC 2 report and has not been through a compliance audit. We do not claim GDPR compliance. We do not offer a Data Processing Agreement yet; it is in preparation, and will be published before general availability. We do not offer a choice of data residency — see where data is processed for what that means concretely.

We have not commissioned a third-party penetration test. We do not run a bug bounty. There is no 24-hour on-call rota and no security team: Calemander is a very small company, and the commitments on this page and on the disclosure page are sized to be ones it can actually keep.

If any of those is a requirement for you, say so at support@calemander.com and we will tell you honestly where it stands rather than where we would like it to be.

See also the privacy policy, the terms of service, and reporting a vulnerability.