I am able to create multiple subscription with same resource and change type.

Question

I am able to create multiple subscription with same resource and change type.

Dhananjay Yadav 0

We are observing unexpected behavior when creating Microsoft Graph change notification subscriptions.

We are able to create multiple active subscriptions with the same resource and changetype.

For example:

Resource: /communications/callRecords

Change type: updated

We create the subscription with the same resource and changeType multiple times. Each request is successful and returns 201 Created, with a different subscriptionId each time.

Expected behavior:

According to the Microsoft Graph documentation, duplicate subscriptions with the same resource and changeType are not allowed. A duplicate subscription request should return 409 Conflict.

Actual behavior:

Multiple requests with the same resource and changeType are being accepted successfully, resulting in multiple active subscriptions for the same resource.

This is particularly concerning for call record change notifications because the same event could potentially be delivered through multiple subscriptions, resulting in duplicate notifications to our webhook.

Could you please confirm whether this is expected behavior, a recent change, or a service-side issue?

If this is not expected, please investigate why the duplicate subscription validation is not returning 409 Conflict.

We can provide the subscription IDs, request/response details, timestamps, request IDs, and tenant information for the affected requests if required.

0 comments

1 answer

Your answer

Answer 1

What you’re seeing does not match Microsoft Graph’s documented behavior. The Create subscription documentation explicitly says that a request using the same changeType and resource as an existing subscription should fail with 409 Conflict. /communications/callRecords is also a supported change-notification resource, and updated is valid for call record notifications

Two checks are worth doing before escalating: list the active subscriptions with the same app identity and confirm the returned objects have exactly the same normalized resource and changeType, then capture the request-id, client-request-id, UTC timestamp, tenant ID, app ID, and both subscription IDs from two consecutive successful duplicate creates. If those match, this is strong evidence for a Microsoft service-side investigation because the documented duplicate subscription behavior) says the second request should be rejected.