Webhooks

Trigger API calls on events, automate workflows and collaborate effortlessly

Overview

Webhooks are a powerful feature used in modern web development and API integrations. They provide a way for applications to communicate and exchange data in real time.

They enable users to trigger API calls to third-party endpoints upon specific events and send relevant asset's information.

The concept behind webhooks is based on the "push" model of communication, where data is actively sent to a predefined endpoint as opposed to the usual "pull" model, where applications need to request data from a server actively.

In the context of Filerobot, webhooks allow users to integrate external systems, automate workflows and stay informed about changes and more generally actions performed on their assets. When a relevant event takes place, such as a new file upload, file renaming or file movement, the webhook is triggered and a POST request is sent to a third-party endpoint, providing details about the the affected asset.

This mechanism allows seamless connections with other applications which enhances collaboration capabilities.

Using webhooks simplifies the delivery of personalized notifications or alerts to assigned recipients whenever essential actions are executed on critical assets. This facilitates prompt responses and efficient communication.

They can also be integrated with project management tools to automatically create tasks, assign responsibilities and track progress whenever assets are uploaded to or moved within the DAM.

Webhook settings

The webhook settings can be accessed from the Developers / Automations / Webhooks menu.

Connection

In order 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 that together with the Hostname forms the complete target URL (Webhook URL) to which the data will be sent.

Authentication

A consumer cannot always verify that the webhook it is receiving is actually 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 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.

Triggers

The triggers determine the events that need to happen in order to execute the webhook. The following ones are available:

a) Asset triggers

  • 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.

b) Metadata triggers

  • On change meta - When any metadata field is modified.

  • 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.

Request body data

There is a 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:

Last updated