Privacy Policy
Last updated: November 2026What our sync engine accesses
The sync engine accesses only the minimum data needed from your Google Calendar:
Event start and end times
To determine when you’re busy
Calendar IDs
To know which calendars to sync
What our sync engine never reads
The sync engine only reads start/end times. It never reads the following:
Event titles or summaries
Event descriptions or notes
Event attendees or organizers
Event locations
Event attachments
How we protect sensitive data
We apply the following protections to the data we handle:
Data minimisation
The sync engine reads only event start and end times. Event content (titles, descriptions, locations and attendees) is never read by sync. Calendar View and search fetch details only when you request them, and MCP clients and connected products fetch them through a token; none of these write event content to our database. The one exception is a queued agent proposal, whose proposed change is kept until it is approved, rejected or expires.
Encryption in transit
In production, all traffic is served over HTTPS with HTTP Strict Transport Security (HSTS), and cookies are marked Secure. ICS feed URLs contain random, unguessable tokens.
Encryption at rest
OAuth access and refresh tokens are encrypted with ChaCha20-Poly1305 before they are stored. OAuth credentials are never stored in plaintext.
Authentication and sessions
Google OAuth is the only sign-in method; no passwords are stored. The session cookie is HttpOnly, Secure and SameSite=Lax, and every user-initiated state-changing request is checked against a CSRF token.
Access control and logging
Authenticated host queries are scoped to the signed-in user, and admin pages require the admin role. Request logs record the path, status and latency, and sync logs record event IDs; event titles, descriptions, locations and attendees are never logged. ICS, confirmation and cancellation links are redacted from logged paths.
Retention and deletion
Event content (titles, descriptions, locations and attendees) is never written to our database, except the proposed change attached to a queued agent proposal, which is deleted when the proposal is approved, rejected or expires. Busy start and end times are stored only as conflict records. Rejected and cancelled bookings remain in the host’s booking history. Deleting your account removes your connected accounts, calendars, settings, booking records and sync history.
Monitoring and reporting
A daily digest email reports sync runs, failures and re-authentication needs to administrators, and in-app alerts notify you when a sync fails or an account needs to be reconnected. Report a privacy concern through the Support page or at [email protected].
How we use your data
Sync Engine
Processes only start/end times. Event titles, descriptions, and attendees are never read by the sync engine.
Calendar View
When you enable the Calendar View, event details (titles, times, descriptions, locations, organizers, attendees, meeting links, and recurrence rules) are fetched from Google when the view needs data and displayed only to you. They are cached in memory for up to 5 minutes, then discarded. They are never written to our database or logged. Search, the event detail and edit forms, RSVP, booking availability and ICS feed generation also read event details on demand; each uses them only to render results, compute busy times, or apply an RSVP you requested, and never writes them to our database.
Scheduling
Your public booking page shows available time slots without revealing event details. No event titles, descriptions, or account details are visible to bookers.
Email alerts
When email is enabled, we send you alerts about booking updates, sync errors, and re-authentication needs through our email provider. These emails never contain your event titles, descriptions, or attendees. You can turn off any alert type from Settings. Email sends are logged for 30 days for troubleshooting.
Access tokens and approvals
You can create agent tokens that let an MCP client read your calendars and propose changes, and integration tokens that let a connected product, such as BusyMail, create and change events. Both kinds of token can read event details on demand, including attendee names and email addresses; the details are returned to the client or connected product and we never store them, and, like the Calendar View and search, they are never written to our database. An integration token's writes and deletes apply immediately, but only to events that token created; only the ids of those events are stored, never their content. A proposed agent change is stored only while it waits for your decision:
Queued changes are kept until decided
A change an agent proposes is stored until you approve or reject it, or until it expires.
Rejected changes are deleted
Rejecting a proposal deletes the proposed event content.
Approved changes are applied and the copy removed
An approved change is written to your calendar through the same path as an edit you make yourself, and the queued copy is deleted with it.
Booking and scheduling
Booker information
Name, email, and timezone are stored to manage bookings
Accepted bookings
A Google Calendar event is created and the booker receives an invite from Google
Rejected bookings
Kept as history with the booker’s name, email and requested time
Cancelled bookings
A record is retained for reference
Per-link ICS feeds
A feed URL you enable publishes the link title, each confirmed booker’s name and the meeting time at an unauthenticated address anyone with the URL can read
Account deletion
Removes all associated booking records
Data storage
Email and display name
From your Google account, stored in our database
OAuth tokens
Encrypted with ChaCha20-Poly1305 before storage
Sync and scheduling settings
Preferences and link configurations
Booking records
Booker name, email, timezone, and time slot
Email send log
Recipient, alert type, and delivery status - kept 30 days
Push subscriptions
A browser or app push endpoint and its keys, stored only while you have notifications turned on and removed when you turn them off
Conflict records
The two account emails and the conflicting time range; removed the next time conflict detection runs for that pair, or kept after dismissal until you delete your account
Google API usage
BusyBlocks requests full calendar access (not read-only) because the service creates and deletes “Busy” block events on your behalf. We also request email and profile scopes for account identification.
Our use of Google API data complies with the Google API Services User Data Policy, including the Limited Use requirements.
You can revoke BusyBlocks’s access at any time from your Google Account permissions page.
Cookies
Session cookie (busyblocks_session)
HttpOnly; keeps you signed in
CSRF cookie (busyblocks_csrf)
Security protection against cross-site request forgery
Calendar view filter cookie (calendar_view_excluded)
Remembers which calendars you hide; expires after one year; Secure on HTTPS
Tracking or analytics cookies
BusyBlocks does not set any. Paddle’s checkout may set its own cookies when you subscribe
Data deletion
Delete your account any time from the Settings page. This removes your profile, connected account records, calendars, settings, booking records, sync history, notifications and push subscriptions from our database. Email send logs keep the recipient address and are deleted after 30 days; the link to your account is removed when you delete it. Busy blocks already created in Google Calendar are not deleted, and BusyBlocks’ access at Google is not revoked; you can remove it from your Google Account permissions. You can also export your data before deletion.
Third parties
We do not use third-party analytics or advertising services. We use the Google Calendar API for calendar access, Resend for delivering email alerts, and Paddle for payments. Paddle’s checkout may set its own cookies and collect payment details when you subscribe. No event titles, descriptions or attendees are ever included in emails.