Page Comparison

...

When subscribing to a change type, each time a corresponding internal event occurs, a notification will be sent to the URL registered for the integration endpoint. For instance, both AssetCreated and AssetDeleted events will trigger the same AssetChanged notification on all endpoints that subscribe to AssetChanged events. The events are debounced to avoid receiving too many identical change events over a short period of time. Thus, a small notification delay is to be expected. An integration endpoint should respond with a 200 OK to successfully received notificationsThe debouncing interval can be configured by adding the following section to the appsettings.json file of the Integration Service:

"Debouncing": {
  "Interval": "<TIMESPAN>"
}

TIMESPAN could for instance have the value 00:00:07, if the debouncing interval should be set to 7 seconds. The default value is 5 seconds.

Note that, it is possible to provide custom headers for the notification HTTP messages when registering an integration endpoint. This, however, is optional.

...

Notifications are, by definition, push-based. Thus, for an integration endpoint to receive notifications it should listen for incoming HTTP POST messages at the registered URL. An integration endpoint should respond with a 200 OK to successfully received notifications. A notification generally has the following JSON-formatted body:

{
  "ChangeType": <the change type of the event>,
  "Data": {
    <specificId>: <specificIdValue>"ItemId": <itemId of the item that triggered the event>,
    "ItemId"<specificId>: <itemId<baseId of the item that triggered the event>
  }
}

The value of the “ChangeType” parameter is an integer, which is used to identify its change type. See the constants in the table above.For each of the change types, an additional data parameter is provided. The specific IDs are<specificId> depends on the change type: