In the case of certain webhook event types like `dm.version.modified` you might get multiple notifications when you think only a single change happened.
All those notifications are correct.
There can be internal and 3rd party systems listening for those notifications and reacting to them in a way that triggers the same event again.
Let's say you are using this filter to check when the SVF2 has been generated for a given Revit file version:
["$[?(@.ext=='rvt')]","$[?(@.custom-metadata.storm:process-state=='PROCESSING_COMPLETE')]","$[?(@.custom-metadata.storm:svf2-extraction-state=='PROCESSING_COMPLETE')]"]As mentioned above, another internal or 3rd party system might be listening to the same event and modifies something on the file version that triggers the same event again.
Since the binary of a file version cannot change, and so its SVF2 cannot change, you could just wait for the first notification that matches the filter and ignore the others.
If you are listening to webhook events from systems that are not flexible enough to deal with this, then you might have to implement a kind of middleware that receives all the notifications, filters them according to your needs, and passes on all the relevant notifications and information to other systems.
