What your admin can see
You are thinking about connecting your work calendar to a tool you found ten minutes ago. Sensible of you to check. Here is the honest answer, including the parts that are not flattering to us.
The short version
Your admin can see that you connected something called sidecal, and what you gave it permission to do. They cannot see what was in your calendar, because we never send them anything and the logs do not record contents. They can block it, and some of them will.
Things your admin can see
All of this is normal. It is the same for every app anyone in your company has ever connected, including the ones nobody thinks twice about.
On Google Workspace
- An app named sidecal, with our client ID, sitting in the admin console under API controls.
- Your email address next to the moment you authorised it. The OAuth log records the user, the app and the permissions granted.
- Every API call we make afterwards: which method, when, and how many bytes came back. Not what was in those bytes.
- All of the above, downloadable as a CSV, because of course.
On Microsoft 365
- sidecal listed under Enterprise applications, with the permissions it was granted.
- Your consent specifically, on the user consent tab. Not just a headcount.
- Sign-in and audit logs covering the same ground.
So this is not invisible, and we are not going to pretend otherwise. If your worry is “will anyone know I did this”, the answer is that a sufficiently curious admin can find out. If your worry is “will anyone find out what is actually in my calendar”, read on, because that is the useful part.
Things your admin cannot see
- The contents of anything we read. Google's own documentation is clear that the logs record that an API was called, not the data it returned.
- Your other calendars. We never tell your employer's systems anything about your personal Google, your side project, or the client account. They are not connected to each other. They are both connected to us.
- Why you are busy. This is the entire point of the product. When someone books you, your other calendars get a block that says [HOLD] and nothing else. No name, no guests, no agenda.
The bit your IT person will ask about
They are going to look at the permission we request, notice it is broader than “read my busy times”, and ask why. Good. Here is the answer before they have to ask.
To put a confirmed booking on your calendar, we need permission to write events. Neither Google nor Microsoft offers a permission that means “tell me when this person is busy, and also let me add one meeting”. Calendar write access is the smallest thing that does the job, and calendar write access comes with calendar read access attached. So the permission looks bigger than the use, and there is no version of this product where it does not.
| What we ask for | What we do with it |
|---|---|
| calendar.readonly Calendars.ReadWrite | Ask when you are busy, across every calendar you chose. We read the start and end times and throw the rest away. |
| calendar.events | Write the confirmed booking to one calendar, and the anonymous holds to the others. Remove them if it is cancelled. |
| userinfo.email User.Read | Know which account you just connected, so we can label it in your calendar list. That is genuinely all. |
| OnlineMeetings.ReadWrite | Put a Teams link on the booking, when the booking wants one. |
The thing that makes this checkable rather than a promise: there is no events table in our database. Nowhere to put your meeting titles even if we wanted them. What we keep is the bookings people make through your own links, and the times we were told you were busy, briefly, in a cache.
What your admin can do about it
Block it. Genuinely, that is the honest answer. Both Google Workspace and Microsoft 365 let an administrator require approval before anyone connects anything, and revoke access afterwards if they change their mind. Plenty of companies run exactly that setting, which is usually a sign of a competent IT department rather than a hostile one.
If yours does, you will find out at the Google or Microsoft permission screen, not halfway through setting things up. You will get a message about needing approval, nothing will connect, and no data will have moved. Ask them, or use a personal calendar instead and leave the work one out of it.
The part to forward to IT
Hello. Someone has sent you this because they would like to use a scheduling tool and would rather ask first. Short version, in the order you are going to want it:
- Permissions requested: calendar read and event write, plus basic profile. Listed in full in the table above, with the reason for each.
- What is stored: busy start and end times, briefly, in a cache. Bookings made through the user's own links. No event titles, no attendees, no descriptions, no events table.
- Where: our own servers in Germany. Data does not leave the EU. OAuth tokens are encrypted at rest, as is booker contact information.
- Reversal: revoke from your admin console at any time, or the user can disconnect from ours. Existing bookings survive, and we stop checking that calendar immediately.
- Who we are: Reluctant Founder Ltd., registered in the UK. Our privacy policy has the full detail and a named human to email.
If that raises a question this page does not answer, mail support@sidecal.co.uk and a person will reply. There are not enough of us for it to be anybody else.
Still would rather not point us at your work calendar?
Reasonable. Connect the personal one, or have a look at the demo, which runs on invented data and asks you for nothing at all.