What we store

The whole list, on one page

The calendar data we store, field by field: what is kept and why, what stays off until you switch it on, and what no setting moves. It is the Privacy Policy’s commitment in plain language.

The one-sentence version

Of your events, we keep the times you are busy, and nothing more unless you ask us to.

Held

What BusyWait keeps, and why

Your email address

To have an account at all, and to email you when a sync breaks.

Until you delete the account.

An access token per connected calendar

To read free/busy and to write the blocks. Encrypted at rest, revocable by you from either end.

Until you disconnect that calendar.

A list of your calendars, by name

So you can pick which ones take part. The name is the one piece of calendar text we hold.

Until you disconnect the account.

Start and end times of events in synced calendars

This is the sync. Without the times there is nothing to mirror.

Rolling — dropped as the events pass out of your sync window.

An opaque ID linking an event to its mirrors

So that moving or cancelling one updates the others instead of orphaning them.

For the life of the event.

Bookings made through your links

The name, email and any answers the person booking chose to give you. Their email address is also used to send them the confirmation.

Until you delete the link it came through, or your account.

Any field you have switched on for a sync

Titles, guests, notes or locations, where you have decided a particular sync should carry them. Off unless you set it.

Until you switch it off or disconnect the calendar.

Not held by default

What we do not keep, unless you ask us to

Titles, guests and notes are not stored or copied by default. The fields on the left can be switched on, one sync at a time, by you. The ones on the right have no switch at all.

Off until you turn it on

  • Event titlesThe name of the thing, carried across to the calendars you choose.
  • Whether a block is a meeting or your own timeLets a client see that Thursday is a call they could ask you to move, rather than focus time they should leave alone.
  • Guest listsThe other guests’ email addresses, written into the block’s description as text. Nobody is invited.
  • Descriptions, notes and agendasThe body of the event, for the syncs where you want the full picture.
  • Locations and video conference linksSo you can join from whichever calendar you happen to be looking at.

Per sync, never per account. Turning titles on between your two work calendars does nothing to the one you share with a client.

Never, at any setting

  • Recordings, transcripts or summaries — there is nothing here to record with
  • Your email, your files or anything outside the calendars you connected
  • Any event from a calendar you did not tick
  • Your calendar as training data — not for our models, not for anyone else’s
  • Your data sold, shared or brokered. There is no second revenue line here

There is no toggle for these, no plan that includes them and no support request that will.

Encrypted at rest and in transit

Access tokens are encrypted at rest, and everything moves over an encrypted connection.

Stored in the EU

Your data is held in the EU, and every service that handles it is named on the sub-processor register.

Deletion means deletion

Delete your account and the record goes, including tokens and stored times. Backups age out afterwards.

Straight answers

What this does not protect you from

The limits of the above, stated plainly.

What you switch on, we necessarily hold
Turn on titles, guests or notes for a sync and those fields pass through us to reach the other calendar. Every switch is per sync and off until you set it.
Sharing guests means sharing other people
A guest list is copied as text: the other guests’ email addresses. Nobody is invited. Those addresses belong to other people, and putting them on another calendar is a decision made on their behalf. We would think twice about it on any sync a client can see.
Calendar access is broader than what we keep
Access that lets BusyWait write a block into a calendar also lets it read the events there. We ask Google and Microsoft for calendar access and nothing else. iCloud works differently: Apple issues an app-specific password, not a calendar-only permission, and BusyWait uses it for your calendar and nothing else. Whatever the provider, a field you have not switched on is not stored or copied, and you can revoke access at the provider without asking us.
Times alone still say something
A mirrored calendar shows when you are busy, and that is information. If a calendar should not learn even that, do not sync into it.

The binding version is the Privacy Policy. Questions that this page does not answer go to privacy@busywait.ai.

The default is the same on every plan

Busy-only, whether you pay us or not. Paid plans let you switch fields on for a sync. No plan switches anything on for you, and no plan moves the floor.