Calendar access
Scheduling that can't read your calendar.
Most schedulers ask to read your events and then promise to be good about it. On Google we ask for a permission that cannot return an event title — not by our restraint, but because Google will not answer that question at all. On Microsoft there is no such permission, and the rest of this page is us saying so.
The scope, printed in full
https://www.googleapis.com/auth/calendar.events.freebusyThat string is not marketing. It is the exact permission our Google connect flow requests, rendered onto this page from the same file the request is built from, so it cannot say one thing here and another at the consent screen. Google's API makes it incapable of returning event titles, guests, descriptions or attachments. A scheduler holding it could not read the name of your one o'clock even if its code tried, and neither can we.
Everything we ask for, and who stops us going further.
Two labels do the work here. Enforced by the API means the provider would refuse us the wider action. Our own limit means the permission allows more and only our code holds the line. A privacy page that blurs those two is selling you the second while sounding like the first.
Google Calendar
https://www.googleapis.com/auth/calendar.events.freebusySo a booking link can't offer a slot you're already committed to. We request the granular free/busy scope, which cannot return event titles, guests, descriptions, or attachments — that limit is enforced by Google, not just promised by us.
https://www.googleapis.com/auth/calendar.calendarlist.readonlySo you can tick which calendars should be checked for conflicts, instead of copying a Calendar ID out of Google's settings and pasting it to us. It returns the list and nothing else: this scope cannot read a single event, and your busy times still come from the free/busy scope above, which Google keeps incapable of returning titles or guests. It is read-only — we cannot add or remove calendars from your list. What it does mean, plainly: we see what your calendars are called.
https://www.googleapis.com/auth/calendar.events.ownedSo a confirmed booking becomes a real calendar invite with a Google Meet link. Google publishes no Calendar scope restricted to the events an app created, so this is the narrowest write scope that lets us book at all — unlike the free/busy line above, this is a limit we keep, not one the API enforces. Our code only ever creates and manages the events Neos Meet books, and never lists or reads your other events. It does not cover calendars merely shared with you.
Microsoft 365
https://graph.microsoft.com/Calendars.ReadWriteSo a booking link can't offer a slot you're already committed to, and so a confirmed booking becomes a real Outlook invite with a Teams link. Microsoft publishes nothing narrower that can do both: it has no equivalent of Google's title-blind free/busy scope, and creating an invite needs write access to the whole mailbox, with no scope restricted to the events an app created. So unlike our Google free/busy grant, this is a limit we keep rather than one the API enforces. What our code actually does with it: read the calendars you tick to find the times you're busy, and create, move and cancel the events Neos Meet books. When we read a calendar we ask Microsoft for four fields only — start, end, busy/free status, and whether the event was cancelled — so your titles, guests and notes are never sent to us at all. That is a stronger limit than promising to look away, and it is still ours to keep rather than Microsoft's to enforce: this permission would allow the wider read, and only our own request stops it.
On Microsoft, this is a promise rather than a wall.
The claim at the top of this page is a Google claim, and it does not carry over. Microsoft publishes no equivalent of Google's title-blind free/busy scope: every way of learning when someone is busy needs an events-read permission, and creating an invite needs write access to the mailbox, with no scope narrowed to the events an application itself created. We request one permission rather than two, because the write scope is a superset of the read and asking for both would widen nothing while lengthening the consent screen.
What actually protects a Microsoft calendar here is narrower than a scope and weaker than a law: when we read one, our code asks Graph for four fields — start, end, busy or free, and whether the event was cancelled. Titles, guests and notes are never sent to us at all. That is better than promising to look away from data you have already received. It is still ours to keep rather than Microsoft's to enforce, and you should weigh it as such.
What you give up by giving up less.
Reading less is not free, and the same tradeoff reads as a defect from the other side of the desk — a Microsoft Bookings administrator, granted calendar-view permission and still shown only Busy blocks, asked what the point of the permission was. The complaint is fair, and it applies to us identically. Because we cannot see titles we cannot tell you which meeting is blocking a slot, cannot offer rules that key off what an event is called, and cannot distinguish a real commitment from a placeholder you abandoned months ago. Every one of those is a feature a nosier scheduler can build and we cannot. If you want them, we keep a list of what the alternatives do better →
Covenant §4 — We see only what we must.
We request the narrowest data permissions that can do the job, we publish exactly what each one allows, and we never widen our access quietly. What we cannot see, we cannot lose, sell, or be subpoenaed for.
The clause is why this page exists in the shape it does. Widening a scope has to change the published disclosure in the same change set — so the cards above are generated from the scope list itself, and there is no version of this site where the request and the description of the request disagree. All eight clauses →
The questions people actually ask.
On Google, no — and not because we choose not to look. The free/busy scope we request is one Google's API will not answer with titles, guests, descriptions or attachments, whatever we send it. On Microsoft the honest answer is different: the permission we hold would allow it, and what stops us is our own code asking for four fields only — start, end, busy/free, and whether the event was cancelled. That is a limit we keep, not one Microsoft enforces, and we would rather you knew which is which.
To not double-book you. A booking page that cannot see your calendar is a page that cheerfully offers a stranger the hour you are already in surgery, on a plane, or asleep. Everything we ask for exists to answer one question — is this person free at this time — plus the write access needed to turn a confirmed booking into a real invite you can find later.
Google shows you the scope list on the consent screen before you approve anything, and every scope we request is printed on this page beside what it allows. Compare the two. You can also revoke us at any time from your Google Account's third-party access settings, without coming back here to ask permission to leave.
Yes, and it is worth saying out loud. Because we cannot read event titles, we cannot do the things that need them: we cannot show you which meeting is blocking a slot, we cannot let you write rules like "never schedule over anything with the word interview in it", and we cannot tell a real commitment from a placeholder you left on your calendar three months ago. A Microsoft Bookings administrator made exactly this complaint about seeing only Busy blocks. If that is what you need, a scheduler with deeper calendar access will serve you better, and you should pick one.
No. The scopes are per-account, and connecting a second calendar grants the same narrow set again rather than a wider one. You also tick which calendars are checked for conflicts, so connecting an account is not the same as offering all of it up.
Busy blocks are read to compute the times a page can offer and are not warehoused for analysis, sold, or used for advertising. Covenant §3 commits to export in one click and §4 to never widening access quietly. If we ever break either, §8 is the clause that says we have to announce it out loud rather than hope nobody notices.
You see the full scope list on Google's consent screen before anything is granted.
Part of the writing index. More on what we store and for how long: privacy and data · security