Subscribe to Google Calendar without giving us OAuth scopes

You can subscribe to your Google Calendar from Emcognito WebMail without going through Google's OAuth flow, without granting any scopes, and without giving us a Google login of any kind. Google publishes a per-user secret iCal URL that returns the same events any authenticated client would see. Paste it into Emcognito and the events overlay on your agenda as read-only. This is how Apple Calendar, Outlook, and every desktop calendar client has subscribed to remote calendars since 2008.

How to do it

1. Open Google Calendar on the web.
2. Hover the calendar you want to subscribe to in the left sidebar, click the three-dot menu, and choose Settings and sharing.
3. Scroll to Integrate calendar.
4. Copy the URL labeled Secret address in iCal format. This URL contains a long random token tied to your account.
5. In Emcognito, go to /calendar, open Subscriptions, and paste the URL.

That is the entire flow. Within a few minutes, the events from that Google Calendar appear on your Emcognito agenda, color-coded, marked read-only, and labeled with the calendar name.

What Emcognito does with the URL

Emcognito's calendar service polls the URL once per hour on the server side, parses the returned .ics body into VEVENT records, and writes them into a per-user subscription cache. They render on your agenda with canRsvp = false, which means the UI does not surface accept/decline/counter affordances on those events. You see them; you cannot mutate them from inside Emcognito.

The token in the URL is stored encrypted at rest. It is treated as a credential because it is one — anyone with the URL can read the calendar, which is the tradeoff of the secret-iCal pattern. We never log the URL in plaintext, never expose it in the UI after the initial save, and never send it anywhere except back to Google to fetch the feed.

What we do not do

This is the part that matters. The Emcognito calendar does not:

• Trigger Google's OAuth consent screen.
• Request any of the Calendar API scopes, which on the default ask include "See, edit, share, and permanently delete all the calendars you can access using Google Calendar." That is the literal scope string Google's consent screen presents. It is the scope every Calendly-style integration and every "connect your calendar" feature in every productivity SaaS asks for, because the OAuth model does not have a finer granularity for cross-calendar read.
• Store a refresh token. There is no token to store. There is a URL.
• Get write access. By definition, a secret-iCal feed is read-only on Google's side. We could not edit your calendar from this subscription even if we wanted to, which is the point.

Why the OAuth ask is the wrong shape for read-only overlay

Google's Calendar OAuth scopes were designed for full client integrations — a product that wants to be your calendar, with read and write and share and delete. There is no scope for "just let me display this person's events on my own calendar UI as read-only." The closest is calendar.events.readonly, which is still a per-API token grant subject to refresh-cycle management and revocable through the user's Google account security page, which most users never visit and many do not know exists.

The secret-iCal URL pattern is the right shape for this job. It is user-issued (the user retrieved it from their own Google account settings), user-revocable (the user can reset the token from the same Google settings page and the old URL stops working immediately), and scope-precise (it grants exactly what it grants: read access to one specific calendar, nothing else). It is also entirely on the user's terms. We never see your Google password, your Google account, or any signal that you have a Google account at all beyond "this URL happens to live on a Google domain."

The same pattern works for Outlook, iCloud, and every other calendar

Microsoft 365 publishes a similar iCal URL under Outlook's calendar settings. iCloud publishes one under the per-calendar sharing menu. Most Calendly-style booking products publish an iCal export feed. Any of them can be pasted into Emcognito subscriptions and rendered as a read-only overlay the same way.

For multi-business operators this is the practical difference between "I have my work calendar accessible from my brand inbox" and "I have OAuth-connected my personal Google account to a five-brand business inbox." The OAuth version is a privacy decision you should not have to make. The iCal version is not.

What you give up

Two things, both worth naming honestly.

You cannot RSVP from Emcognito to a Google Calendar event you subscribed to via iCal. The feed is read-only and there is no protocol for sending an accept back through it. If you want to accept a Google Calendar invite, you do that in Google Calendar. The Emcognito overlay shows you the event so you do not double-book; it does not let you modify it.

The poll cadence is hourly, not real-time. A change you make on the Google side will appear on Emcognito within an hour. For most users this is fine. If you need second-by-second sync, the OAuth integration with Google's webhook channels is the only way to get it, and most multi-business operators decide the privacy tradeoff is not worth the latency improvement.

FAQ

How do I subscribe to my Google Calendar without giving an app full access?

In Google Calendar's web UI, open the calendar's settings, scroll to "Integrate calendar," and copy the URL labeled "Secret address in iCal format." Paste that URL into any app that accepts iCal subscriptions — such as Apple Calendar, Outlook, or Emcognito WebMail — and the events will sync as read-only. No OAuth flow, no Google sign-in, no permission grants.

Is the secret iCal address safer than OAuth for a Google Calendar subscription?

It is more privacy-preserving for the read-only overlay use case. The secret iCal URL grants exactly what it grants — read access to one specific calendar, no edit, no share, no delete, no access to other calendars in the same Google account. OAuth's default Calendar scope grants substantially more. Both are revocable by the user from their Google account settings.

Why does Emcognito not use Google's Calendar OAuth integration?

The Calendar OAuth scopes are designed for full client integrations that read and write a calendar. Emcognito only needs to display Google Calendar events on its own agenda as read-only, and the secret iCal URL pattern delivers that with a strictly smaller permission grant, no refresh-token storage, and no consent-screen ask. For multi-business operators juggling multiple identities, avoiding the OAuth flow is also a usability win.

Can I subscribe to Outlook or iCloud calendars the same way?

Yes. Microsoft 365 and iCloud both publish per-calendar iCal URLs from their respective settings UIs. Paste either one into Emcognito's subscriptions panel and the events overlay on your agenda the same way a Google Calendar subscription does.

How often does Emcognito refresh subscribed calendar events?

Once per hour. A change made on the source calendar will appear in Emcognito within an hour of the change. This is the standard refresh cadence for iCal subscriptions across calendar clients.

Related reading. How we built calendar push notifications without a Google account and Why every email client with a calendar should ship METHOD:COUNTER.

Set up your first subscription at /calendar, compare against Google Workspace at /compare/google-workspace, or read the multi-business case at /for/multi-business.