Microsoft Graph Webhook/Subscription, getting multiple post to my notificationUrl
Asked Answered
M

2

11

Im trying to receive push notification on calendar events through microsoft graph

the notificationURL points to webservice which is running on NodeJS

subscription I have made has these options.

   {
   "changeType": "created,updated,deleted",
   "notificationUrl": "myurl",
   "resource": "users/userid/events?$filter=sensitivity%20eq%20%27Normal%27",
   "expirationDateTime":"2016-11-05T18:23:45.9356913Z",
   "clientState": "customclientstate"
}

however im getting multiple POST calls(2~4) coming from subscription(all of them having identical body) whenever a single event is changed.

there is only one subscription active, a single calendar, and i am responding to the request with status code 204 without any content(tested with postman).

its a huge problem since im updating DB whenever the request comes in.

has anyone run into this problem? ive been looking all over without any results.

any input would be greatly appreciated!! =).

Marinna answered 3/11, 2016 at 22:24 Comment(2)
I cannot repro the problem you are seeing. Did you get multiple notifications on create or update events? Can you check whether the notification payloads are identical by looking at the subscriptionId and changeType property? Notice that deleting an event triggers 2 notifications, one is updated, and one is deleted. It might be possible that you created 2 or more subscriptions that share the same notificationUrl.Markmarkdown
multiple event coming in have the same subscription id. and i get multiple notifications on both create and update. I thought it was the case of having two subscription with same notificationURL but after deleting all subscription and making sure i wasnt getting any notification, ive tried again with the single subscription only to get multiple notificationMarinna
E
11

I have this same issue. When creating new event in office calendar I'll get everytime one notification with ChangeType: Created and at the same time three notifications with ChangeType: Updated. When I'm cancelling event in office I get always 3 x Updated notifications and finally 1 x ChangeType: Deleted.

What you can do here is to use ChangeKey validation. Everytime you get new notification from office you have to request that event from API, right?

Once you fetched that event you can check if event.ChangeKey property has changed.

It's same thing as etag in websites. If content changes, etag hash changes.

So when you get Created notification, take that event's ChangeKey and store it to array or db and whenever you get notification remember to validate if you have that event's ID already in array or db and also if ChangeKey has changed. If ChangeKey is same as last time, you won't need to update that event in db.

This also works with recurring events, if even one occurrence has changed SeriesMaster event's ChangeKey also changes.

Edmundson answered 29/11, 2016 at 21:46 Comment(6)
Thanks, very useful. It's 2020 and I wish Microsoft sent the ChangeKey (or some sort of a changelog) in their Notification in the first place. That could save a ton of time, and it's good for them as well (less incoming traffic to infer the change).Bibb
It's 2022, i am still not able to get through this... I get multiple notification. Is there a way to track if anything actually changed from merely the data that we received in notification at the first place. Any help from anyone is highly appreciated!!Blouson
it's almost end of 2022 and I'm still finding it hard to track the changes. My API is getting flooded by notifications for only 1 event change. I don't know what will happen when 1000 user will start using my app simultaneously :(Despoliation
It's 2023, I'm still facing the above mentioned troubles. Any help regarding this will be appreciated.Anglican
its almost 2024. same issue, very poor response from microsoft. This is a big problem when I have 20000 users, as there is no way to stop this callback flooding,Angelita
it's 2024 and still the same problemOracular
P
0

Given the number of "It's 2024 and it's still happening" and I eneded up here without a clear answer I thought I would add the following:

Personally I found that making sure I returned the correct responses assisted in cutting down the extra callbacks - in fact if I follow the below for creates I will only get 1 call.

as per: https://learn.microsoft.com/en-us/graph/change-notifications-delivery-webhooks?tabs=http

If I can get processing done in less than 3 seconds, do what needs to be done and then return a 200 OK like below.

  await $.respond({
  status: 200,
    headers: { "Content-Type": "text/plain" },
    body: "OK" 
  }); 

If it's going to take longer than 3 seconds then responding with a 202 Accepted

However I found that unless I responded with the 200 in less than 2.5 - 3 seconds I would almost always get a second message from another server.

I also started to return 400 Bad Request to extra messages that I should not be getting (old subscriptions that are still responding, or updates when I'm only I should only be getting creates). This seems to remove subscriptions that have been deleted but are still responding.

If something goes wrong then repond with a 500 Internal Server Error, then this will leave the request queued at Microsoft and they will retry.

The other thing I have noticed is that you can get multiple responses from different servers - I assume the email store servers. If your request is still pending and you have not given MS the 200 OK message above.

The other thing is that you should be checking if you need to actually do an update, otherwise you will end up with a loop if you respond to an update with an update which then notifies you of an update....

Hope this helps.

Projection answered 13/7, 2024 at 23:21 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.