Skip to main content
Cover illustration for: Calendar Privacy: Why We Don't Store Your Events on Our Servers
Engineering

Calendar Privacy: Why We Don't Store Your Events on Our Servers

Your calendar is among the most personal data you have. We treat it that way: read-only access, processed in your browser, nothing kept.

April 27, 20262 min read

Calendar Privacy: Why We Don't Store Your Events on Our Servers

Your calendar is unusually intimate data. It says who you talk to, what you work on, when you are in therapy, when you have a job interview, when you are off sick. Most people have never thought about handing it to a third party — until a timesheet tool asked them to.

We thought about it a lot. Here is the architecture we settled on.

Three commitments

  1. Read-only. We request only the minimum scopes needed to read events. We cannot create, edit, or delete anything on your calendar. Ever.
  2. Processed in your browser. Event data is fetched directly from your calendar to your device. The mapping, grouping, and Excel generation happen client-side.
  3. Nothing stored by default. Generating a timesheet does not persist your events on our servers. Close the tab, the data is gone.

What about automation?

If you turn on optional features like scheduled email delivery or cross-device sync, we do need to store an encrypted refresh token so we can run the job for you. We tell you exactly when this happens, you consent explicitly, and you can revoke it from the dashboard or your provider's account at any time.

For everyone else — most users — there is no server-side token, no event log, no analytics on what your meetings were about.

What competitors often do (and we do not)

  • Sync entire calendars into their database "for performance"
  • Mine event titles for product analytics
  • Train models on your meeting patterns
  • Keep data after account deletion
We have read the privacy pages. They are usually long. Ours is short on purpose: we keep what we must, for the features you turn on, and not a row more.

Why this is a real differentiator

Privacy-first architecture is harder to build than the alternative. It limits how clever the product can get on the server side, and it forces us to do real engineering in the browser. We accept that trade because trust is the only thing that matters with calendar data.

If a tool ever feels like it is asking for too much, it probably is. There is no reason a timesheet app needs to permanently warehouse your weekly schedule.

A clean exit, always

Delete your account and your data is gone — for real, not "deactivated." Disconnect a calendar and the connection is severed at the provider level.

Read our integration scopes → and decide for yourself.