Outlooh Webhook subscription send multiple triggers for webhook receiver when i do one action

Question

Hi Microsoft Team,

We are using Microsoft Graph webhook subscriptions for Outlook room calendar events.

When we create or update only one room calendar event, our webhook receiver is triggered multiple times for the same action.

For example, for one booking create or update, we receive multiple webhook calls like:

created

updated

updated

updated

Sometimes, when we update one existing event, the webhook first sends created and then updated.

Because of this, our system may process the same booking multiple times and create duplicate records.

We want to understand the expected behavior of Microsoft Graph webhooks for Outlook room calendars.

Our questions are:

1. Is it expected that one Outlook room calendar event can trigger multiple webhook notifications?
2. Why does one event creation trigger both created and updated notifications?
3. Why does an event update sometimes trigger created first and then updated?
4. Is there any way to receive only one final notification for the actual user action?
5. Is there any way to avoid internal Outlook/Exchange update notifications?
6. What is the recommended way to identify and ignore duplicate webhook notifications?
7. Should we use event id, change key, iCalUId, or last modified time to detect duplicate notifications?
8. For room calendars, what is the best practice to process only the final real event change?
9. Can Microsoft Graph guarantee that only one webhook notification will be sent for one user action?
10. If duplicate notifications are expected, what is Microsoft’s recommended design pattern to prevent duplicate processing?

We need guidance because duplicate webhook triggers are causing duplicate booking creation/update in our application.

Example issue:

User creates one Outlook room event.

But webhook receiver receives multiple calls:

1st call: created

2nd call: updated

3rd call: updated

4th call: updated

Expected:

Only one notification for the actual event creation.

Actual:

Multiple notifications are received for the same event.

Answer 1

Hi @Venujan v ,

Graph webhooks for Outlook room calendars can indeed fire multiple times for what looks like “one” user action. Here’s what’s happening and how to handle it:

1. Why you see multiple notifications

• Internal system updates: when you create an event, Exchange makes a series of internal changes to the mailbox (mailbox store, resource mailbox, etc.), so you see a “created” plus one or more “updated” notifications. The same goes for an update it may write the change in stages, bumping the changeKey multiple times.
• No single “final” notification: Graph can’t collapse all of those internal writes into one “final” call for you. There’s no Graph guarantee of exactly one callback per user action.

2. Can you suppress internal updates? Unfortunately, no. There’s no Graph subscription flag to “only give me the last update” or to filter out Exchange’s internal mailbox writes.
3. How to avoid duplicate processing Design your webhook receiver to be idempotent. Common patterns are:

• Persist the combination of event id + changeKey (the @odata.etag in the resourceData). Only process when you see a new changeKey.
• You can also use the iCalUId (same across series of related updates) and the lastModifiedDateTime.
• On each notification, look up the stored latest changeKey/timestamp. If the incoming changeKey is identical or older, skip it.

4. Best practice for room calendars

• Store for each event: event id + latest changeKey.
• When you get a notification, fetch the event from Graph (GET /users/{roomMailbox}/events/{id}) and compare its lastModifiedDateTime or ETag to what you’ve stored. Only act if it’s newer.
• This way, even if you get created→updated→updated, only your first “new” changeKey triggers business logic.

5. Design pattern recap

• Assume Graph notifications are “at least once,” not “exactly once.”
• Make your processing idempotent using event id + changeKey or timestamp.
• Optionally poll the single event after debouncing your notification stream, e.g. queue notifications for 1–2 seconds, then fetch once.

6. Below are the answers to your questions
   1. Yes, one user action can generate multiple internals that fire separate Graph notifications.
   2/3. Creation writes and updates under‐the‐covers, so you see both. 4/5. There is no subscription setting to collapse or filter out those internal updates. 6/7/8. Dedupe by tracking id + changeKey (ETag) or lastModifiedDateTime (and/or iCalUId).
   9. No, Microsoft Graph can’t guarantee a single callback per action.
   10. Build your consumer to handle duplicates as described above.

Hope that helps you avoid duplicate bookings!

References:

• Action or notification happened more than once

Hope this helps!

---

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.