Clarification on Duplicate Subscription Behavior for Microsoft Graph Webhook Notifications

Question

Hello Microsoft Support Team,

I would like to request clarification regarding an inconsistency between the Microsoft Graph documentation and the observed behavior in production when creating change notification subscriptions.

According to the documentation:

Duplicate subscriptions aren't allowed. When a subscription request contains the same values for changeType and resource as an existing subscription, the request fails with HTTP 409 Conflict.

Reference: Change notifications via Webhooks – Subscription Request (Section: Duplicate subscriptions aren't allowed)

However, during our implementation, we have noticed that duplicate subscriptions are successfully created for the same mailbox resource and changeType. When a new email arrives, Microsoft Graph sends duplicate callback requests to our service — one per subscription.

Example: For the following resource:

Users('<user-id>')/messages

We received notifications coming from different subscription IDs:

SubscriptionId: <Removed for PII> (Environment: dev)

SubscriptionId: <Removed for PII>(Environment: qa)

Both subscriptions are delivering change notifications for the same message event at the same time.

---

Request for Clarification

Is the current behavior expected where multiple subscriptions with identical resource and changeType are allowed to coexist?

If not, is this a known issue or a temporary deviation from the documented behavior?

Should we enforce deduplication on our service side, or is Microsoft Graph expected to return HTTP 409 Conflict for such subscription requests?

---

Additional Context

Approx. date/time when duplicate notifications were observed: 2025-10-27T11:43:28+08:00
We can provide full logs and subscription creation requests if needed.

---

Thank you in advance for your support. Looking forward to your response!

Best regards,

<Removed for PII>

Answer 1

Hi @Weiwilliam,

Welcome to Microsoft Q&A, and thank you very much for reaching out to us.

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Please note that I’m a Microsoft Q&A community moderator, not part of the Microsoft Support team. Therefore, I can only provide guidance based on publicly available documentation and community insights. That said, I’ll do my best to assist you as much as possible.

Based on your description, you are correct. According to the Microsoft Graph Subscription documentation, when a subscription request contains the same values for changeType and resource as an existing subscription, and all relevant properties match, the request should fail with an HTTP 409 Conflict error.

However, as I checked, the subscription ID you provided is tied to different environments (Dev and QA), which likely explains why both are active. This usually happens because each environment can have its own app registration, tokens, and endpoints. When the notificationUrl points to different endpoints, Graph treats them as separate subscriptions.

Your logs also show distinct clientState values. While optional, these can make subscriptions appear unique in practice.

From my research, this behavior has also been reported by multiple users in the community, indicating that it is expected when subscriptions differ by environment or configuration.

Regarding deduplication enforcement, it’s strongly recommended because duplicate notifications can happen when multiple subscriptions target the same resource and changeType (the behavior you’re seeing now) or when retries occur due to network issues.

Based on this Microsoft article, the service will keep retrying for up to four hours if delivery fails, using exponential backoff. This means your endpoint needs to be resilient and prepared for repeated notifications. Since the same event can be sent more than once, your processing logic should be idempotent to avoid handling duplicates incorrectly.

If you believe this behavior should not occur and want stricter enforcement of the documented rule, I recommend submitting feedback or reporting it as a potential bug through the Microsoft Feedback portal. The more users raise this concern, the more likely Microsoft will investigate and prioritize a fix.

Additionally, if you’d like to contact the Microsoft Support Team, you can raise a ticket through the Microsoft Admin portal or use the phone numbers listed in this Microsoft Article here.

Thank you very much for your time. If you have any other questions or need further clarification, feel free to let me know. I’ll be happy to assist you further.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".     

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.