iCal link in Google Calendar: subscribing instead of importing

Two different jobs get searched for with the same words. One is getting an iCal link out of Google Calendar so that something else can read the schedule. The other is putting someone else's iCal link into Google Calendar so that their events appear alongside yours. The menus look similar, the file format is the same, and the outcomes are nothing alike.

The cost of mixing them up is usually discovered a week later, when a meeting that moved is still sitting at its old time in one of the two calendars. Almost every complaint about iCal links being unreliable turns out to be a copy that was never meant to update, or a feed that is updating on a schedule nobody chose.

Getting a link out of Google Calendar

Google gives each calendar more than one address, and they are not interchangeable. All of them live in the same place: open Google Calendar in a browser, go to Settings, click the calendar's name in the list of calendars you own, and scroll to Integrate calendar.

The Secret address in iCal format is the one most instructions mean. It lets another application read that calendar without signing in to anything, which is exactly why Google's page states that only you should know it and that sharing it is a mistake. Next to it is a Reset control, which invalidates the old address and issues a new one. Treat the secret address as a password that happens to look like a URL.

The Public address in iCal format sits in the same panel and only works if the calendar has been made public. That is a separate switch, under Access permissions for events, called Make available to public. Google notes that turning it on usually takes a few minutes but can take up to four hours to take effect, which is long enough for someone to conclude the address is broken and start over.

The Public URL to this calendar is a browser link rather than a feed. It opens the calendar in a web view without asking the visitor to sign in or subscribe. Alongside it, under Access permissions for events, Get shareable link produces the address to hand to someone who should subscribe rather than just look.

One failure has a simple cause. If the secret address is missing from the panel entirely, and the account belongs to a company or a school, an administrator has changed the sharing settings. Google's page says so directly, and no amount of refreshing will bring the field back.

Putting an outside link into Google Calendar

On the receiving side, Google Calendar offers two routes that look adjacent in the menu and behave completely differently.

Next to Other calendars there is Subscribe to calendar, which takes an email address, and From URL, which takes a web address. The email route is limited in a way worth memorizing: Google states that you cannot subscribe to calendars that are not from Google. Typing a colleague's address works only when that colleague is on Google.

The URL route is what an .ics feed is for. Google's condition is that the other person's calendar must be public. A secret address pasted in here belongs to a calendar that was never published, and the result is an error or an empty calendar rather than a helpful message.

Two more constraints matter in practice. Subscribing to a new calendar has to be done in a computer web browser; it cannot be done in the Google Calendar app on Android, iPhone or iPad, although a calendar subscribed on a computer then shows up in the app. And Google warns that beyond four hundred subscribed calendars, browsing calendars can get slow, which is a real ceiling for anyone who subscribes to a feed per project or per sports team.

The field asks for the URL of the published calendar. Addresses handed out as webcal are the same address wearing a different scheme, so if a paste is refused, the https form of the same string is the first thing to try.

Subscribe or import, which is the actual decision

This is the choice that determines whether anything stays current, and it is worth making deliberately rather than by whichever menu item was found first.

	Subscribe from a URL	Import an .ics file
Stays up to date	Yes, on the service's schedule	No, frozen at the moment of import
Editable in Google Calendar	No	Yes
Guests carried across	Not applicable	No
Meeting links carried across	Not applicable	No
Lands as	A calendar under Other calendars	Events inside a calendar you pick
Right for	Watching a schedule someone else owns	Moving history into an account for good

Importing is done through Settings, then Import and Export, and it accepts .ics and .csv files. Google is explicit about two losses: when an event is imported, its guests and its conference data are not imported. An imported meeting is a block of time with a title, not a meeting. Anyone migrating a year of calls should expect to lose every attendee list and every video link in the process.

A few import mechanics save time. An export from Google Calendar arrives as a .zip containing one .ics file per calendar, and those files have to be taken out and imported one at a time. Repeating events brought in from a .csv file may land as a series of separate one-time events rather than a recurrence. And Google notes that imported events do not stay in sync between two accounts, so if the goal was to keep two accounts aligned, sharing the calendar is the mechanism, not importing.

When Google refuses the file

An import that ends in an error is usually a formatting problem in the file rather than a problem with the calendar, and Google's page says as much: if an iCalendar file produces an error, the formatting can often be repaired by hand.

The structure is fixed. The first line of an .ics file is always BEGIN:VCALENDAR, followed by header information such as VERSION:2.0 and a PRODID value identifying the software that wrote it. The last line is END:VCALENDAR. Between them, each event sits between a BEGIN:VEVENT line and an END:VEVENT line. That shape is defined by RFC 5545, the specification the format comes from, which is why files from unrelated applications can be opened in the same calendar at all.

Two practical consequences follow. A file that was truncated during a download, or that had its header stripped by a tool in the middle, will fail the moment the header or footer is missing, and adding the missing line back is the whole fix. And a file assembled by hand, which happens more often than expected when a schedule is generated from a spreadsheet, needs the header and footer present in every file rather than once across a set of them.

Google's own suggestion is worth taking: export a calendar from Google Calendar first and use that file as the reference for what a valid one looks like. Comparing a rejected file against a known good one takes less time than reading the specification, and it settles arguments about which side produced the broken file.

Why a subscribed feed looks stale

A subscribed calendar refreshes when the service decides, and Google Calendar does not expose a refresh setting for a calendar added from a URL. There is no button that means fetch this now. For a feed of public holidays that is irrelevant. For a booking system that writes a new appointment twenty minutes before it starts, it is the whole problem.

This is where the choice of calendar application matters more than the choice of feed. Apple's Calendar on a Mac handles the same .ics URL through File, then New Calendar Subscription, and its setup panel includes an Auto-refresh menu where the interval is chosen explicitly, along with a Location menu that decides whether the subscription lives in iCloud, and therefore on every device, or only on that Mac. The events in a subscribed calendar are still controlled by whoever publishes it, and Apple's documentation is clear that a subscribed calendar cannot be edited; what changes is that the refresh interval is a decision rather than a mystery.

The same holds for any desktop calendar that overlays webcal or ICS feeds directly instead of routing them through a Google account. If holiday calendars, school terms or fixture lists are the reason for the feed, putting them in the app that displays them keeps them out of the Google account entirely, which also keeps them off every other device signed in to it. Compared with other calendars sets out which applications treat subscriptions as a first-class object rather than a list of URLs.

One more stale-looking case has nothing to do with refresh. If a calendar was made public minutes ago, the subscriber may be reading it before the change has propagated. Waiting out the four hours Google mentions is cheaper than resetting addresses.

Treating the secret address as a credential

The secret address is the part of this that carries real risk, because it works forever and it works for anybody.

Anyone holding it can read every event title, time and location on that calendar without signing in, and nothing in the calendar records that they did. It is not scoped, it is not expiring, and it cannot be revoked for one holder: the only control is Reset, which breaks it for everyone at once, including every integration that was quietly using it.

That leads to two working rules. Paste a secret address only into software that is going to be trusted with the whole calendar, and keep a note of everywhere it has been pasted, because a reset will require redoing all of them. When something needs read access to only part of the schedule, the better answer is a separate calendar containing only those events, with its own address.

For the opposite direction, where the point is to let other people see when you are free rather than what you are doing, the free or busy option under Access permissions for events hides details while leaving the times visible. That covers most of the reasons a secret address gets shared in the first place. How that plays out for booking a meeting is covered in the Guide.

What to change first

Look at every iCal link currently in use and label it as either a subscription or a copy, then fix the ones that are the wrong kind: a copy of a schedule that keeps changing, or a subscription to something that only needed importing once. If any of those feeds needs to be current within the hour, move it into a desktop calendar where the refresh interval is set explicitly rather than into the Google account. Caltimate overlays webcal and ICS feeds directly on a Mac and keeps them out of the Google account.