Webhooks
Webhooks allow you to call a third-party web service upon specific triggers and send all asset data in the JSON body.
Last updated
Webhooks allow you to call a third-party web service upon specific triggers and send all asset data in the JSON body.
Last updated
The Webhooks can be accessed from the Settings > DAM > Automations > Webhooks menu.
You can add up to 5, individually configured and activated, webhooks.
Webhook url
Target webhook url to POST event to
Hostname
The domain address of the third party service where to post data
Path
The domain path to post data to
Basic Authentication
Requires a Username and a password
oAuth2 Authentication
Requires an authentication endpoint (with https://), a username and a password
To set up the webhook, the following information must be provided:
Hostname - The domain name of the third-party API that will be contacted.
Path - The specific path with the Hostname forms the complete target URL (Webhook URL) to which the data will be sent.
A consumer cannot always verify that the webhook it receives is coming from the expected source. Due to this, there are two authentication methods supported:
Basic authentication - The simplest way to verify a webhook. It makes use of a username and a password that are used for authentication when sending the data to the Webhook URL.
OAuth2 authentication - A more secure and complex authentication method that allows users to grant limited access to their resources without exposing their credentials. This type of authentication can be used in two ways:
By specifying the Authentication endpoint, username and password to retrieve a temporary token, which is then used in the webhook.
By directly entering the Static bearer token to use every time without generating a temporary one before the request.
You can specify up to 10 additional headers to be sent to the endpoint with the payload. Those headers will have the classic form name:value:
The triggers determine the events that need to happen to execute the webhook. The following ones are available:
On upload - After a successful asset upload.
On move - When the asset location is changed.
On rename - When the asset is renamed.
On delete - When the asset is deleted.
On change meta - When some specific (or any) metadata field is modified to a value (or any).
On change info - When some asset's information (e.g. title, description, etc.) is changed.
On change tag - When the asset's tags are edited.
On change label - When the asset's labels are modified.
There is fine-grained control over which specific asset details are sent as part of the request JSON body to the selected API endpoint. This ensures that only the necessary information to handle the event effectively is communicated. Those details are divided into several categories depending on the asset type:
Name
Width
Width
All system metadata*
Size
Height
Height
All custom metadata*
Path
Length (in seconds)
All embedded metadata*
MIME type
Bitrate
CDN link
HLS/DASH playlist URL
File UUID
* those global metadata packages to send along will include everything that is recorded for the asset in each of the 3 categories.
eg. for system metadata, it includes the file hash, labels, etc.
Note that for embedded metadata, it can be very voluminous, please only add if really necessary.
