Microsoft Graph subscriptions can't monitor recurring events instances

Billy | IKANDA 11 Reputation points


So I have been building my API to use the Microsoft Graph Subscriptions to read the events of a resource mailbox calendar.

Everything seems to work, the only issue is that when you work with recurring events then all of a sudden you can't check the instances.

It only returns the ID of the master event for that recurring series, while the update wasn't applied to the master but an instance of that recurring series.

Especially when you try to delete an instance of the series no matter how far you delete it in the future it will always send a notification for the entire series, making it kinda impossible to know what instances got deleted...

Any ideas on how to handle recurring events with subscriptions perfectly?

Cause I'm kinda getting clueless on how to process this accordingly.

Thanks in advance!

Kind regards,


PS: I also added it on: Stackoverflow

Microsoft Graph
Microsoft Graph
A Microsoft programmability model that exposes REST APIs and client libraries to access data on Microsoft 365 services.
11,323 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Deepanshu Sharma 490 Reputation points Microsoft Vendor

    Hello @Billy | IKANDA handling recurring events with subscriptions can indeed be tricky, especially when dealing with instances and updates. Let’s break down some strategies to address this challenge:

    1. Master Event vs. Instances:
      • You’ve correctly observed that when working with recurring events, the subscription only returns the ID of the master event. This is because recurring events are essentially a series with a common pattern (the master event) and individual occurrences (instances).
        • To handle instances, you’ll need to retrieve the master event and then use recurrence information (such as the recurrence pattern and range) to generate the instances yourself.
    2. Instance Retrieval:
      • After receiving the master event ID, you can use the recurrence pattern (e.g., daily, weekly) and the start date to calculate the instances.
        • For example, if the master event is a weekly meeting starting on Monday, you can calculate all the Mondays within the specified range to get the instances.
    3. Tracking Updates:
      • When an update occurs (e.g., an instance is modified), you’ll receive a notification for the master event. However, you won’t know which specific instance was updated.
        • To handle this, maintain a mapping between the master event and its instances. When an update notification arrives, compare the updated master event with the instances to identify the affected instance(s).
    4. Deletion Notifications:
      • Deleting an instance can indeed be challenging due to the notification behavior you described.
        • One approach is to track deletions separately. When you receive a deletion notification for the entire series, mark the corresponding instance(s) as deleted.
          • You can also use the RecurrenceMasterId property to link the deleted instance back to the master event.
    5. Granularity of Subscriptions:
      • Consider the granularity of your subscriptions. You might need separate subscriptions for master events and instances.
        • For instance updates, subscribe to changes on individual instances. For master event updates (e.g., recurrence pattern changes), subscribe to the master event.
    6. Testing and Edge Cases:
      • Test thoroughly with various recurrence patterns (daily, weekly, monthly) and edge cases (e.g., exceptions, modified instances).
        • Consider scenarios like exceptions (cancellations or modifications to specific instances) and how they affect the overall series.