Event logs
An overview of the eventlog and contentlog endpoints
Last updated
An overview of the eventlog and contentlog endpoints
Last updated
The event log tells you what has happened after a last known event. Depending on your use-case you can either process the eventlog from the beginning (it keeps a history of one month), or start at the last event. It's useful to process all retained events if you want to prepopulate a cache, but if you just need it for invalidation of a cache that you start cold and build ad-hoc it makes more sense to start with the last event.
A request to the eventlog looks like this: GET
If called without any query parameters you get events from the start of the log:
The contentlog event id is not consistent when migrating to a new version/install of OC either (it gets "compacted"), so depending on it as state for long-running tasks is not recommended.
If you pass in a negative value, like so GET , you get the last -N events in the log.
The id attribute in the events can be used to paginate though the eventlog. So if we have processed events up until 406374 we would ask the eventlog for all events after it, like so GET :
To fetch the updated object the normal objects endpoint is used GET
To get a log that covers all content in OC you must use the contentlog instead (). It comes with some other trade-offs though as it only contains the last event for every object and it doesn't publish any delete events. That means that it is useful for bootstrapping f.ex. a cache with a full data set, but not very useful for invalidation.