What a scheduling app can read in your calendar

Two permissions, and the gap between them

Google Calendar exposes scheduling-relevant data through separate OAuth scopes. The two that matter here are not variations of the same thing.

calendar.freebusy returns intervals. For a given calendar and a given window, it answers with a list of the periods that are taken: busy 10:00 to 10:30, busy 14:00 to 15:00. There is no title in the response, no guest list, no description, no location and no attachment. There is no field for them. An app holding this scope and nothing else cannot learn what any of your meetings are, because the API it is calling does not carry that.

calendar.events and calendar.readonly return events. That means the title, the description, who is invited, where it is and what is attached, for everything in the calendar. These are the scopes that let an app create the booking on your calendar afterwards, which is why most schedulers need one, and they are also the scopes that let an app list everything already in it.

The gap between those two is the whole question, and the consent screen is where it is stated. “See when you are busy or free” is the first. “See, edit, share and permanently delete all the calendars you can access” is the second.

Why most schedulers hold the broad one

Because they write. Showing your availability needs free/busy. Putting the confirmed booking on your calendar with a video link, inviting your guest so it lands on theirs, moving it when somebody reschedules and removing it when somebody cancels all need write access to events, and Google does not offer a write-only scope. There is no way to create an event without also being able to read events.

So the broad grant is usually real and usually necessary. What varies is whether the product says so. A privacy policy that says “calendar access” where the grant says calendar.events is not lying, exactly, but it is choosing the word that prompts fewer questions.

How to check what you have already granted

• Open your Google Account and go to Data and privacy, then Third-party apps and services.
• Every app you have connected is listed, with the access each one holds spelled out in the same language the consent screen used.
• Removing access there is immediate and does not need the app’s cooperation. It is the right first move if you are unsure, because reconnecting takes a minute and leaving a forgotten grant in place does not.

Worth doing once a year regardless of which scheduler you use. The list is usually longer than people expect, and most of it is things tried once.

What Meetrao asks for

Two calendar scopes, and the Privacy Policy names both in full because Google’s verification review compares that table against the consent screen.

• calendar.freebusy, used every time somebody opens your booking page, so a slot you already have something in is never offered. This is the only thing the booking page consults.
• calendar.events, used to create the event for a confirmed booking with its Google Meet link, invite your guest, update or delete that event when the booking changes, and read whether your guest accepted it, by that event’s own identifier rather than by listing or searching your calendar.

The second is broader than the use made of it. That is a property of Google’s scopes rather than a choice, and the honest thing is to write it down rather than let “calendar access” do the work. Meetrao does not sell your data or your guests’ data, and does not use either to train machine-learning models; both are stated in the policy rather than only here.

Questions worth asking any scheduler

• Which OAuth scopes does the consent screen name, and does the privacy policy use the same words?
• Does the booking page itself read events, or only free/busy?
• What happens to the data when the account is deleted, and is there a grace-period copy?
• Is the data used to train anything?
• Who else receives it, and is that list separate from the general list of subprocessors?

The last one catches more than it looks like it should. A policy often has one list of everybody who helps run the service and no separate answer to the narrower question of who receives calendar data specifically, and those are different lists.

Questions