Forum Discussion
Duplicate subscriptions for a specific resource
Microsoft's current subscription-creation documentation still says duplicate resource and changeType combinations should return 409 Conflict. Your screenshot appears to show matching callRecords resources, change types, and application identifiers, but that alone does not confirm an announced feature change. Compare the complete, unmasked identifiers privately and establish whether the first subscription was still unexpired when the second request succeeded; the screenshot shows different expiration dates. Capture both creation requests, their API versions, timestamps, response statuses, and request IDs, then reproduce with a minimal test in the same tenant. If both subscriptions were simultaneously active with identical relevant settings, raise a Microsoft support case as behavior inconsistent with the documented contract. Do not build production logic around duplicates being accepted until Microsoft clarifies it. Renew an existing subscription through its update operation when that is the objective, and make notification processing tolerant of repeated deliveries.
- sandy73Sep 13, 2026Copper Contributor
Hello Jamony,
Thank you for the detailed response.
However, I am able to reproduce the issue consistently. I can create multiple duplicate subscriptions at the same time using the same application ID and the same resource/change type combination.
Previously, when we attempted to create a duplicate subscription with the same configuration, the API returned a 409 Conflict as expected. However, currently, the second subscription is being created successfully without any error response.
On our side, we have already implemented logic to check whether a subscription exists for the given resource before creating a new one. If no existing subscription is found, we create a new subscription. Despite this check, we are still seeing duplicate subscriptions being created.
Could you please help clarify where we might be missing something in our implementation or whether there has been any recent change in the Microsoft Graph subscription behavior?
I can provide the complete request/response details, including the API versions, timestamps, expiration times, and request IDs, if that would help investigate the behavior.
Our main concern is understanding why the API is now accepting duplicate subscriptions (Even if there is active subscription exists for a same resource) when previously the same request resulted in a 409 Conflict.