Creating Graph subscriptions does not honor duplicated behavior

Question

According to this document, creating a duplicated Graph subscription with POST API should incur 409 conflict error.

POST https://graph.microsoft.com/v1.0/subscriptions

https://learn.microsoft.com/en-us/graph/api/subscription-post-subscriptions?view=graph-rest-1.0&tabs=http#duplicate-subscription-behavior

This behavior has been expected until it's broken recently. I made 2 duplicated POST requests with exact identical payload, and 2 different subscriptions was created for the same resource and same target (Event Hub).

For example,

POST https://graph.microsoft.com/v1.0/subscriptions
Authorization: Bearer {{TOKEN}}
Content-Type: application/json

{
  "changeType": "updated",
  "notificationUrl": "EventHub:https://spod-test.servicebus.windows.net/eventhubname/spod-graph-notification?**PII Removed**",
  "resource": "**PII Removed**",
  "expirationDateTime":"2026-02-28T23:59:59.000Z"
}


// first call, 201 created

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#subscriptions/$entity",
  "id": "**PII Removed**",
  "resource": "**PII Removed**",
  "applicationId": "**PII Removed**",
  "changeType": "updated",
  "clientState": null,
  "notificationUrl": "EventHub:https://spod-test.servicebus.windows.net/eventhubname/spod-graph-notification?tenantId=kevinzhucahotmail.onmicrosoft.com",
  "notificationQueryOptions": null,
  "lifecycleNotificationUrl": null,
  "expirationDateTime": "2026-02-28T23:59:59Z",
  "creatorId": "**PII Removed**",
  "includeResourceData": null,
  "latestSupportedTlsVersion": null,
  "encryptionCertificate": null,
  "encryptionCertificateId": null,
  "notificationUrlAppId": null
}

// make the same POST request again
// 201 created

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#subscriptions/$entity",
  "id": "**PII Removed**",
  "resource": "**PII Removed**",
  "applicationId": "**PII Removed**",
  "changeType": "updated",
  "clientState": null,
  "notificationUrl": "EventHub:https://spod-test.servicebus.windows.net/eventhubname/spod-graph-notification?**PII Removed**",
  "notificationQueryOptions": null,
  "lifecycleNotificationUrl": null,
  "expirationDateTime": "2026-02-28T23:59:59Z",
  "creatorId": "**PII Removed**",
  "includeResourceData": null,
  "latestSupportedTlsVersion": null,
  "encryptionCertificate": null,
  "encryptionCertificateId": null,
  "notificationUrlAppId": null
}

These 2 subscriptions can also be listed in GET /subscriptions API.

Answer 1

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.

---

Hi Kevin Zhu,

Welcome to Microsoft Q&A Forum! 

Have a good day and I hope you're doing well! 

Thank you for bringing this detailed observation to our attention. I completely understand your concern relying on the 409 Conflict response is a standard pattern for handling idempotency, and seeing the API behavior deviate from the documentation can certainly disrupt your application logic. 

I have personally tested this in my own environment, and I was able to reproduce the exact behavior you described. 

To verify if this was specific to Event Hubs or a broader issue, I performed a test using a standard Webhook notification URL: 

1. First Attempt: I sent a POST request to create a subscription for a SharePoint List. The API returned 201 Created with a new Subscription ID. 

2. Second Attempt: I immediately sent the exact same request (same resource, notificationUrl, and expirationDateTime).  

• Expected: 409 Conflict (as per documentation). 
• Actual Result: The API returned 201 Created again, generating a duplicate subscription. 

Here is the screenshot from my test: 

Note: The IDs and data shown in the screenshot are generated in a sandbox testing environment and are for demonstration purposes only.

Since this behavior appears to be an inconsistency with the current Microsoft Graph documentation and affects the backend service logic, it requires attention from the engineering team. 

I highly recommend posting this issue directly to the Microsoft Graph Q&A on GitHub Community. This is the primary channel where Microsoft Graph product managers and engineers monitor feedback regarding API behaviors. By posting there, you ensure that the right experts can investigate this regression and work towards a fix. 

I hope this confirmation helps validate your findings and points you in the right direction. Please let me know if there is anything else I can clarify for you. 

Best regards. 

---

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.