Privacy Policy

Two different relationships, and mixing them up is how a policy stops being useful.

For your account — your email, name, password, billing status, sign-in history, the settings you choose — we are the controller. We decided to collect it, we decide how long to keep it, and this policy is our accounting for it.

For what is inside your calendars we are the processor. You decide which calendars to connect and what flows where; we act on those instructions and on nothing else. If you are a business and that distinction matters to your paperwork, the Data Processing Addendum is the contract for it and applies automatically.

Where we are processor, requests from the people whose events they are come to you rather than to us — you are the one who knows who they are. We will help.

If you are in the EEA, the UK or Switzerland, the GDPR asks for a lawful basis per purpose. These are ours.

• Running the service — your account, your calendar connections, the syncing itself. Article 6(1)(b), performance of the contract you entered when you signed up. Without this there is no product.
• Keeping the account secure — the security log, rate limiting, two-factor. Article 6(1)(f), our legitimate interest in the service not being broken into, which we think is also plainly yours. We keep it to the minimum that works: device and browser, never an IP address.
• Billing — plan, dates, the Stripe customer id. Article 6(1)(b) for taking the payment, and 6(1)(c) where tax or accounting law requires us to keep a record.
• Operational email — reconnect and sync-health alerts, trial and billing notices, password and security confirmations, and team-membership changes. Article 6(1)(b): these are the service telling you something you need to know. Optional setup guidance, product updates, conflict summaries, and the Monday digest can be controlled from Notification settings.
• Contact requests: the name, reply address, topic, and message you submit. Article 6(1)(b) when you ask for account or product help, and Article 6(1)(f), our legitimate interest in answering other questions you choose to send.
• Analytics — Article 6(1)(a), your consent, and only if you give it. Decline and nothing is set.
• Knowing which channel you came from — campaign attribution is optional and uses the same analytics consent, under Article 6(1)(a). These records hold campaign labels and referring sites, not your name or email.

We never rely on legitimate interests for anything a reasonable person would be surprised by, and we do no profiling and no automated decision-making that has any legal or comparable effect on you.

• Your account email and name — from Google sign-in, or entered directly if you create an account with an email and password.
• If you contact us: the name, email address, topic, and message you submit. The website does not add that message to the product database; it is delivered to our support inbox by Resend.
• If you use a password: a salted, one-way hash of it (bcrypt). We never store plaintext passwords.
• An encrypted authorization token (AES-256-GCM) for each calendar account you connect.
• The list of your calendars (names, colors, timezones) and the sync rules you configure.
• For Outlook, we request read-only mailbox settings access to discover and store the time zone for your default calendar. We read the time zone without changing your mailbox settings. Shared calendars and unsupported zones can use a time zone you choose manually.
• If you use the migration guide: the competitor you are leaving, calendar and sync counts, workflow status, and notes you choose to give support. We never ask for or store a competitor password.
• Mapping records that link a source event to its copy — identifiers and timestamps only, never content.
• A sync activity log (action, status, timestamp) so you and we can see that syncing works.
• A security log of account events — sign-ins, failed sign-in attempts, password changes, calendar connections and disconnections, and two-factor changes — each with a timestamp and the browser and operating system reported by your device (for example “Chrome on Windows”). You can read your own log under Settings, and it exists so you can spot access you don't recognise. We do not record IP addresses. The log is deleted with your account.
• If you turn on two-factor authentication: an encrypted authenticator secret and one-way hashes of your recovery codes. We cannot read either back, which is also why we cannot recover them for you.
• Billing status: your plan, your trial dates, and the Stripe customer id that ties your account to your subscription. Stripe takes the payment itself. Card numbers go straight to Stripe and never reach us.

How long each thing lives, rather than just what deletes it:

• Tokens, calendars, rules, mappings — until you disconnect or delete. No separate clock.
• Sync activity log — rolling 90 days, then dropped. It exists so you can see syncing works, and an older log line answers little.
• Security log — rolling 180 days, or until you delete the account. Long enough to investigate access you did not recognise.
• Billing records — kept while the account exists and then as long as tax and accounting law requires, which in the United States is seven years. This is the one thing deleting your account does not immediately erase, and the law is why.
• Attribution cookie — 30 days in your browser, read once if you sign up.
• Analytics — 14 months in Google Analytics, and only if you accepted it. Browser consent receipts expire after 365 days. Our delivery and duplicate-prevention records are retained for up to 90 days.
• Private backups — one encrypted-in-transit logical snapshot each day, with the newest 30 snapshots retained in a private Vercel Blob store for service-wide disaster recovery. Deleting your account removes it from the live service immediately; a copy may remain in those snapshots until the retention cycle replaces it. We do not use a backup to recover an individual deleted account. If a full-service restore is ever required, deletion requests made after that snapshot are reapplied before normal service resumes.

Most of these you can exercise yourself, without asking and without waiting for us. Settings › Your data downloads everything we hold in one file; Billing deletes the account outright.

• Access — the JSON export, any time, no request needed.
• Portability — the same file, machine-readable, plus per-calendar .ics.
• Correction — your name and email in Settings; email us for anything else.
• Erasure — delete the account from Billing, or ask and we'll do it inside 30 days.
• Restriction and objection — email us. Where we rely on legitimate interests (the security log) you can object and we will stop unless we have a compelling reason not to, which we will explain rather than assert.
• Withdrawing consent — the analytics cookie is the only thing we ask consent for. Reopen the banner or clear this site's data.
• Complaining to a regulator — you can go to your own supervisory authority at any time, and you do not have to come to us first. In Ireland that is the Data Protection Commission, in the UK the Information Commissioner's Office, in Switzerland the FDPIC. We would rather you gave us the chance to fix it, but it is your right either way.

We answer inside 30 days and charge nothing. We do not discriminate against anyone for exercising any of this — no worse price, no degraded service.

California. We do not sell personal information and we do not share it for cross-context behavioural advertising, as the CCPA and CPRA define those terms — not as a policy choice we might revisit quietly, but because there is no advertising integration in this product to sell it to. We collect identifiers (email, name), commercial information (your plan and billing status), internet activity (which pages of our own site you visited, if you accepted analytics), and the calendar metadata described above. We do not collect sensitive personal information as the CPRA defines it, so there is nothing for a “limit the use of my sensitive personal information” request to limit. Everything in the list above is available to you as a California resident, and you may use an authorised agent.

Where your data lives. Our infrastructure is in the United States, so using Sync My Cal from the EEA, the UK or Switzerland means a transfer there. That transfer is covered by the EU Standard Contractual Clauses, incorporated into the Data Processing Addendum, with the UK Addendum and the Swiss equivalent where relevant. Consent is deliberately not what we rely on for the transfer — an earlier version of this page said that using the service meant you understood your data went to the US, which is not a transfer mechanism the GDPR recognises.