The short version. The only calendar read we perform is an availability query that returns busy time ranges. We do not list your events. We never receive, store or log a meeting body, an attachment, or an attendee list.
An administrator approves these once for the organization. Nothing is installed on devices. Publisher verification with Microsoft is in progress; until it completes, the consent screen does not show Micro Fitness Club Corp as a verified publisher.
| Platform | Identifier |
|---|---|
| Microsoft Entra application (client) ID | 33ff9a35-309f-421c-b907-85dd7a00b15f |
| Microsoft home tenant | d223793b-5017-4721-b799-8f23ee32d842 |
| Google OAuth client ID | 682689439316-tl1n4afmvaofqm5c8vgoqonrvrpfkdmm.apps.googleusercontent.com |
The home tenant is the directory the application is registered in. It is not your company's tenant. Approval still happens in your own Microsoft Entra admin center, or in the Google Admin console.
Placing a session on your own calendar requires a permission that also technically allows reading it — neither Google nor Microsoft offers a write-only calendar scope. So the meaningful question is not what we are permitted to call. It is what we actually call. Here is the complete list.
| Purpose | Call | What comes back |
|---|---|---|
| Find your open windows | freebusy.query | Busy start and end times only. The API returns no summary, no attendees and no description. There is nothing for us to discard. |
| Find sessions we placed | events.list, filtered | Filtered to a private property we stamp on our own events, so the only events returned are ones this app created. |
| Place, move or remove a session | events.insert / patch / delete | Our events only. |
| Notice a meeting moved | events.watch | A ping with no payload. Google sends headers only; we then re-run the availability query. |
We request two calendar scopes: calendar.freebusy, which Google classifies as non-sensitive and which is our entire read path, and calendar.events, which is required to place a session on your calendar and to be told when a meeting moves. We previously also requested calendar.readonly and have removed it.
We hold one delegated permission, Calendars.ReadWrite, plus User.Read and offline_access. Graph has no free/busy-only permission — the one that sounds like it, Calendars.ReadBasic, still exposes subjects and attendees and requires admin consent, so it is worse on both counts.
Instead, the query we run on every sync selects only id, start, end, isAllDay, isCancelled, showAs and our own private property. Subject is deliberately not requested, so Graph does not send us a meeting title — not yours, and not even our own. Change notifications carry no resource data.
We would rather you read these here than find them yourself.
Neither runs on the sync path that operates for every user every day.
| Data | Stored |
|---|---|
| Your busy time ranges | No. Read at sync time, used to choose a gap, then discarded. |
| Meeting titles, attendees, bodies, attachments | Never received. |
| Sessions we placed | Yes — the event id, time, type and duration. |
| Calendar refresh token | Yes, encrypted at rest. |
| Your work email, team membership, preferences, minutes completed | Yes. |
| Provider | Purpose |
|---|---|
| Vercel | Application hosting |
| Upstash | Database |
| Stripe | Payments |
| Resend | Transactional email |
| Cloudflare (R2) | Session video storage, served over short-lived signed links |
| Mux | Video playback for older session recordings |
We will give notice before adding a sub-processor that processes customer data.
An administrator can remove a person from the console at any time, and a SCIM deprovision (Okta or Microsoft Entra) does the same. Doing so revokes our Google calendar grant, or for Outlook stops the subscription and deletes the only copy of the refresh token, and deletes the upcoming sessions we placed on that calendar. Deleting a workspace removes its members, tokens and records. Anyone can also revoke our access directly from their Google or Microsoft account security settings, which stops all access immediately.
To request deletion, write to hello@microfitnessclub.com from your work address.
If we become aware of a security incident affecting customer data, we will investigate immediately, contain it, and notify affected administrators by email without undue delay and in any case within 72 hours of confirming it, with what we know, what we are doing, and what we recommend you do. To report something, write to hello@microfitnessclub.com — we would rather hear it from you than not hear it.
Micro Fitness Club’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not use Google user data for advertising, we do not sell it, and we do not use it to train machine-learning models.
We are a young company and we are not going to overstate this.
If SOC 2 is a hard requirement for your organization today, tell us — it is useful for us to know, and we would rather you heard it straight than discovered it three weeks into a review.
Tell us where to send it and we will reply with what exists today — the data-flow description above in document form, our DPA, a completed security questionnaire and a W-9 — plus a straight answer on anything still in progress.