Mapping Office365 REST Calendar IDs to EWS CalendarItem IDs

Question

Using Exchange push notifications I've been creating a service that syncs over calendar data from Office365 users. I've been using a combination of the Office365 Calendar REST API (to get and manage calendars) and the EWS API (to subscribe to calendar changes).

I noticed that just recently MS has introduced a preview API for their subscription endpoints. However, this API is still in preview mode and I'd like to avoid using it for the time being.

Once I have everything setup, the problem is I can't make a correlation between the calendar event resource (REST) and the EWS CalendarItem resource that is returned on a push notification. The ItemId for the CalendarItem and the Id for the REST event differ.

When attempting to update the events that I've saved from the REST API this proves problematic since I cannot find a good method of associating the two.

Any help is greatly appreciated!

Edit After some further digging, I've actually found that the calendars that are returned from the REST API (GET /calendars) appear to be Message items within the EWS hierarchy. So instead of this endpoint returning actual Folder IDs, it returns Item IDs that belong in some folder called "Common Views".

I'm not sure why things are designed this way, but the difference in the base64 encoded IDs seems to be very minimal. I just still can't figure out a good way to associate the two.

Numeration

I believe the Id's are the same between REST and EWS however the one's EWS returns aren't URL safe (eg in the REST Id they have swapped + for _ not sure of the exact standard they have used though) – Atony

The Ids are definitely URL safe now, but they definitely differ (I'm pretty sure they're all base64 encoded): REST AQMkADczMwE5OQAxYS0wZDBkLTQwY... EWS AQAhAHphY2hAcm9iaW5wb3dlcmVk... – Numeration

Okay I see something different (The Id's you posted look to me like they are from different folders) but you really need a response from one of the MS Guys to give the exact format that has been used. – Atony

Yeah sorry those were actually calendar/folder IDs. Here are some full event IDs: EWS: AAAhAHphY2hAcm9iaW5wb3dlcmVkLm9ubWljcm9zb2Z0LmNvbQBGAAAAAACQzFDXMzIoTqAJh4U8y/HNBwAf+IOmOMCuSpQ5Xg7LdVyrAAAAAAENAAAf+IOmOMCuSpQ5Xg7LdVyrAABR3P8DAAA= REST: AAMkADczMzM5OTFhLTBkMGQtNDBiMC1hYzVlLWM0MTIwMzUzMjBhZABGAAAAAACQzFDXMzIoTqAJh4U8y-HNBwAf_IOmOMCuSpQ5Xg7LdVyrAAAAAAENAAAf_IOmOMCuSpQ5Xg7LdVyrAABR3P8DAAA= It looks like the IDs match up at some point, but not at the start. – Numeration

Answer 1

So it turns out that my IDs mismatched due to subscribing to EWS push notifications via the Exchange2007 version. Exchange2007_SP1 and beyond have compatible EwsIds with each other so this includes Office365.

Replacing - characters with / and _ characters with + allows me to properly make calls to Office365 API resources.

Finally, when making a call to get calendars, the API is actually returning Message item types that live under the Common Views folder. So when attempting to use these IDs for subscriptions, the EWS API will complain that I've sent it ItemIDs and not a Folder ID.

Thankfully I've found that making a request to the REST API via GET /calendars/ews_folder_id actually works once you properly translate the ID to a URI safe type (see above conversion).

Numeration

Have you come across any other characters(apart from '-' and '_') that may require replacement? – Aslant

GET /calendars/ews_folder_id - Have you found any document etc explaining this behaviour? – Aslant