Understanding the asset event webhook service

The service monitors asset changes in CMP and delivers them to one or more configured webhook endpoints. It executes approximately every minute, collecting any asset change events that occurred in that window and delivering them as a single HTTP POST request with a JSON body.

Each delivery contains a count of events included, a webhookTimestamp indicating when the payload was generated, and an events array containing one or more individual change records. The receiving endpoint must return a 2xx HTTP response to acknowledge successful delivery. If it does not, the service retries delivery up to five times using exponential backoff, starting at one minute between attempts and increasing to a maximum of eight minutes. Client errors (4xx) are not retried. Events that cannot be delivered within 24 hours are dropped.

The webhook service monitors all CMP asset types, including resources, projects, and sub-assets.

The supertype field in the event payload identifies the entity type, allowing receiving systems to distinguish between, for example, a file asset and a project asset and handle them differently.

The supported supertypes are Resource, Project, Adaptation, and Template. Note that child assets of Resource, Adaptation, and Template may not emit events depending on their internal configuration; project events are always emitted. If you are not receiving events for a specific sub-hierarchy, contact App Support.

By default, the service only delivers events for top-level assets (those with no parent). Child assets are excluded unless the configuration explicitly includes them using a parentId filter. See Configure asset event webhook filters for how to include child assets.

Each webhook POST may contain multiple events, up to a default maximum of 100 events per request. Payloads are capped at 16 MB. Where asset activity is high, multiple payloads may be delivered within a short period.

One important behaviour to understand is how EDITED events are grouped. If an asset is edited multiple times within a single delivery interval, these changes are collapsed into a single EDITED event rather than generating one event per change. For example, if a user updates the name, description, and keywords within the same minute, all three changes appear as a single EDITED event. The payload reflects the state of the asset at the point of delivery, not each individual change that occurred.

This has implications for filter design. If you are filtering on a specific field value, the filter evaluates against the asset’s state at the end of the delivery interval, not each intermediate state within it.

When the webhook executes, each event passes through a series of checks before being included in the delivered payload. Understanding this evaluation order helps explain why a particular event did or did not trigger delivery.

The service evaluates events in the following order:

Within a single filter group, the condition field controls how values are matched: AND requires all values to be present, ANY requires at least one, and NONE excludes assets that have any of the specified values.

To illustrate how this combines: if you configure a keyword filter requiring CORE AND a state filter requiring Approved, an asset must satisfy both independently. An asset tagged CORE but in Draft state would be rejected at the state filter stage.

See Asset event webhook service reference for the complete filter kinds and conditions specification.

The service supports API key authentication via the x-api-key request header. OAuth is not supported.

API key values are specified at configuration time. Key rotation is a manual process and must be handled through App Support. Additional custom headers can also be added to webhook requests. Contact App Support to specify them.

The service is designed for near-real-time delivery with automatic retry on failure, but integrators should be aware of several important constraints before designing their receiving systems.

Receiving systems should be designed with these constraints in mind. Where downstream processes depend on complete event history, consider maintaining your own event log on receipt rather than relying on the ability to replay from CMP.