Google Calendar API V3: Identifying edited one-offs of recurring events? - google-calendar-api

Question

I am currently listing all events from a Google Calendar using the "singleEvents" parameter set to true, which splits recurring events into individual events – which is good. However, I'm running into an issue when an instance of a recurring event is edited, and the edits are saved with the "Only this event" option in the Calendar UI.
What I need to do is be able to identify which of these recurring event instances have been edited, and which have not. It seems the API response data does not provide any indications of whether this is an instance of the unedited recurring event, or an edited one-off. The response for an unedited instance of a recurring event and an edited instance are more-or-less the same, save the description field, which was edited.
The reason I need to differentiate edited versus unedited recurring event instances is that I am dynamically creating event detail pages from the list of single events. I would like to have one page be for the recurring event itself, and another for a "one-off" of that recurring event. E.g:
allmyevents.com/events/my-recurring-event --> page showing recurring event with recurrence information
allmyevents.com/events/my-recurring-event/16-4-2020 --> page showing specific instance of recurring event, which has been edited
Currently, I'm able to do this by creating an entirely new event at the same date and with the same title as the recurring event instance I want to replace, and writing hacky comparison logic to tell if this is a replacement event, but this is counter-intuitive for event/content management.

Answer 1

Answer:
You can use the Calendar API Events: instances endpoint to return all instances of a recurring event. All the events which have been edited on their own will not be returned.
More Information:
The Events: instances endpoint of the Calendar API will return all instances of a recurring event for a calendarId and eventId specified. Any of these that have been edited are omitted.
It's a bit of a workaround, as these events can't be obtained directly, but by obtaining the list of events as you have already been doing and then removing the events which are returned by Events: instances, you can build a list of all the events which have been edited with the 'Only this event' option.
Psuedo-code:
You can do something like this:
eventsList = Calendar.Events.List(calendarId, singleEvents=true)
eventsInstances = Calendar.Events.Instances(calendarId, recurringEventId)
singleEvents = eventsList
for each instance in eventsInstances :
if eventsList.items contains instance :
singleEvents.remove(instance)
return singleEvents
Where the returned singleEvents variable will be a list of all the events that have been edited manually.
References:
Events: instances | Calendar API | Google Developers
Recurring Events | Calendar API | Google Developers

Answer 2

I've been puzzling through this same issue, and I think I've found a way forward that doesn't involve going through every single instance to check if they've been moved/edited:
Each event returned by the Calendar API has an iCalUID field. For a standalone event, this should match the event's id, with an #google.com suffix. e.g. an event with the id of abcdef has an iCalUID of abcdef#google.com.
When it comes to recurring series, every single instance of that event has the same iCalUID value - and, most importantly, you can use iCalUID as a filter when listing events, which will return the main recurring series event and all modified instances. Unmodified instances are not returned.
Tracking which instances have been deleted is slightly more fiddly. They might be returned in the list with the matching iCalUID, but with a status set to cancelled. Or, they may be specified within the recurrence property (an array of strings) on the main series event as timestamps (within the given time-zone, which should match whichever time-zone the main series event uses):
[
"RRULE:FREQ=WEEKLY,COUNT=5",
"EXDATE;TZID=Australia/Melbourne:20211227T110000,20220103T110000"
]
I haven't figured out why some recurring events use the specific-instances-as-cancelled approach, and others use the EXDATE approach (and I think they can also be combined, so don't presume the presence of one rules out the other). Given both are possible, you'll have to allow for that.