Notifications enable you to recognise what has changed recently.
In general, when you begin consuming the notification resource, you should use the current date and time. It is possible to specify a date up to 90 days ago, however if you want to consume older notifications please contact your support representative.
The response includes a list of Notifications, where each Notification resource represents content that has been modified on or after the values provided in the request; and a list of links, containing the url to use in retrieving the next set of results, so that you don’t miss any changes.
When you are following the next link from a previous notifications response, you should use that URI without alteration. Otherwise, you can make a request with the following query parameters:
The start date and time: any content created, updated or deleted since this date should be returned. A valid since parameter must be supplied, and it must be in RFC3339 date time format, for UTC timezone: e.g. 2017-01-06T10:00:00.000Z The date and time must not be in the future, and cannot be older than 90 days from the present.
Do not supply a request body with this method.
A list of notifications for content that has been updated based on the query parameters supplied. This may be an empty list if no content has changed.
400 Bad Request
The request could not be understood by the server due to malformed syntax
200 OK - A list of notifications for content that has been updated based on the query parameters supplied
The next URL in the links array should be used to retrieve the next set of results.
You should not assume that there are no more results because there are fewer than 200 resources. Instead, keep following the next URLs until there are no more notifications.
Even if there are no notifications right now, you should still use the next URL when you next poll the notifications API.
The next URL will contain query parameters other than since. To avoid gaps and reduce duplicates these should be passed unchanged to the API the next time you call it. If you build your own URL with since, you may miss notifications or receive a large proportion of duplicate notifications.
Sometimes you will receive notifications for content that you are not permitted to access. Clients should cope with this situation, for example by ignoring this content and continuing.
Sometimes you will receive notifications for content of new types, which have different attributes in the /content endpoint. (For example the bodyXML may not be present.) Clients should cope with this situation, for example by ignoring content they do not understand.