Why am I receiving duplicate event.updated webhooks with different object IDs for the same Microsoft recurring series?

This is expected Microsoft recurring event behavior when the same series appears in multiple calendar views with different organizer perspectives. Microsoft Graph API maintains separate internal representations for the same recurring series, creating what appears to be duplicate events with different object IDs.

Understanding the Issue

When you have a single recurring meeting series in Microsoft/Outlook calendar, you may receive multiple event.updated webhooks with different data.object.id values, even though there's only one series visible to the user. This happens because Microsoft creates different "perspectives" of the same event:

• Organizer perspective: The event as seen by the meeting organizer
• Attendee perspective: A "shadow copy" that Microsoft creates for calendar view logic

Both perspectives represent the same recurring series but have different Nylas event IDs.

What's identical between both perspectives:

ical_uid: The iCalendar unique identifier (your primary deduplication key)
title, description, location: Event content
recurrence rules and when timing
organizer and participants information

What differs between perspectives:

id: Different Nylas event IDs
calendar_id: May point to different calendar views
created_at/updated_at: May have slight timestamp differences

Recommended Deduplication Strategy

To handle these "shadow copies" effectively, you must implement a strategy that prioritizes the authoritative version of the event while maintaining a consistent view for your users.

Step 1: Use ical_uid as the Primary Identifier

The ical_uid field is the only identifier that remains constant across both organizer and attendee perspectives. Use this field as your primary database key for deduplication.

Step 2: Compare organizer.email with the Grant Email

Because the is_organizer boolean is unavailable, you must manually determine the user's role by comparing the event's organizer to the authenticated account.

• Organizer Perspective: If webhook.data.object.organizer.email matches the email address associated with your Grant ID, this is the "primary" copy with full management rights.

• Attendee Perspective: If the emails do not match, the webhook represents a "shadow copy" created for the attendee's calendar view.

Step 3: Differentiate by calendar_id

Microsoft typically places the organizer's perspective on the primary calendar.

• Action: Check the calendar_id in the webhook payload.

• Logic: Attendee perspectives may appear on different or shared calendar views, whereas the organizer copy is almost always tied to the main calendar of the account.

The "Orphan Master" Sync Issue

In some v3 sync scenarios (especially long-running series), the /events/import endpoint may return a Master event (where master_event_id is null) without expanding its instances in the same response.

• Impact: After deduplicating by ical_uid, the version you persist may be missing its occurrences.

• Workaround: If you identify a master with no instances, perform a follow-up call to the /events endpoint using the master_event_id filter to fetch the missing series data.

Updated April 27, 2026 17:06