Webhook notifications

Last updated: Apr-10-2023

Cloudinary provides a webhook notification feature for informing your backend about certain actions that have been completed, either from an upload API method, or from a user action within the Media Library. When the action is completed an HTTP POST request is sent to a notification URL you provide, and the data will contain all the results pertinent to that particular action. This means that you also need to set up a URL in your application that's accessible from the public web.

By default, Cloudinary's upload API works synchronously. For example, uploaded assets are processed and eager transformations are generated synchronously during an upload API call, which means that the original asset and derived assets are available immediately for delivery and further management. However, in some cases you may need to be notified that an upload has completed, or you may want to process actions asynchronously in the background, especially actions that require a relatively long time to process and require your users to actively wait for the processing to finish.

Tip
Although not its primary purpose, you can also potentially use Cloudinary notification webhooks as a trigger for another operation. The Cloudinary Solutions team took advantage of this option to create an open-source library that can learn and then auto-tag faces with names using an Amazon Rekognition lambda function that's triggered by the notification when photos are uploaded to a dedicated 'training' folder in Cloudinary.

Global notification URL

You can set a global Notification URL in the Upload page of the Console Settings. Once configured, Cloudinary automatically sends responses to that URL address any time:

  • A user performs a certain action in the Media Library. For more details about the list of actions that trigger a notification, see the Media Library notifications topic below.
  • You run any Cloudinary upload API method that supports the notification_url parameter, but without specifically setting a value for the notification_url parameter. When the notification_url parameter is included in the method call, then the value set there overrides the global value. For more details, see the Upload API notifications topic below.

Notification Payload

When an action that triggers a notification is completed, an HTTP POST request will be sent to the notification URL you provided. The post data will contain all the result details for the action that triggered it. The body of this POST request is essentially the same information as you get in response to a standard synchronous request.

Here's an example POST request sent by Cloudinary after an upload completes:

For additional examples of notification responses from various API calls, see notification response examples.

Note
If you would like to include the initiating client IP Address in the response sent to your notification, please contact us.

Upload API notifications

In specific situations, you may want to notify your backend as soon as a method call is complete, for example when dealing with user initiated uploads from a browser or mobile device. You can tell Cloudinary to notify your application as soon as the method is complete by adding the notification_url parameter to the method call and setting it to any valid HTTP or HTTPS URL.

The following upload API methods support the notification_url parameter: upload, explicit, explode, generate_archive, sprite, multi and create_collage.

For example, to add a notification_url to a specific upload call:

Media Library notifications

To enable Media Library notifications, you have to configure your product environment's Global notification URL.

When a user performs any of the following actions in the Media Library, it will trigger a notification and send it to your global notification URL:

  • Uploading a new asset.
  • Renaming the asset's public ID.
  • Deleting an asset. Deleting a folder that contains assets will also trigger a delete notification for all individual assets in that folder. Note that deleting empty folders does not send a notification.
  • Updating an asset's display name. (Relevant only for product environments using dynamic folder mode.)
  • Moving an asset between folders.
    • In fixed folder mode, moving an asset to another folder in the Media Library changes the public_id value, and thus triggers a rename notification.
    • In dynamic folder mode, moving an asset to another folder changes the asset_folder value, and triggers a move notification.
  • Adding, removing or updating the Contextual metadata for an asset.
  • Adding, removing or updating the Structured Metadata for an asset.
  • Adding or removing a Tag for an asset.
  • Updating the Access control setting for an asset.
  • Creating a new Folder.

For some examples of notification responses from these types of operations, see the Notification response examples section.

Note
If Dynamic folders mode is enabled on your product environment, there are some additional operations in the API and Media Library that can trigger notifications as well as some additional keys that will be included in some notification responses. For details, see dynamic folders notifications.

Eager transformation notifications

You can instruct Cloudinary to send a separate notification whenever a requested Eager transformation completes by adding the eager_notification_url parameter to the method call and setting it to any valid HTTP or HTTPS webhook URL. Eager transformations should be set up to work asynchronously in the background after an upload completes by also including the eager_async parameter (for more details, see Eager asynchronous transformations). This eager notification is in addition to any notification sent via the optional notification_url parameter.

The following upload API methods support the eager_notification_url parameter: upload and explicit.

For example, the following method will upload the sample.jpg image and then eagerly generate two transformed images:

  1. Pad to a width and height of 300 pixels.
  2. Crop to a width of 160 pixels and a height of 100 pixels.

Furthermore, the transformations will be performed asynchronously after the image finishes uploading, with a callback URL to notify your application once the upload is complete, and a different callback URL to notify your application once the eager transformations are complete:

Notification combinations with eager

The following table shows the results of adding different notification parameters when also requesting eager transformations with and without, the eager_async parameter.

Parameters Result
eager andnotification_url The upload method response and the notification_url are sent after BOTH the upload completes and the eager transformations have finished.
eager andeager_notification_url The upload method response and the eager_notification_url are sent after BOTH the upload completes and the eager transformations have finished.
eager andeager_notification_url andeager_async - The upload method response is sent after the upload completes and include a batch_id for tracking the eager job. - eager_notification_url is sent after the eager transformations have finished with a batch_id for tracking.
eager andnotification_url andeager_notification_url The upload method response and the notification_url are sent after BOTH the upload completes and the eager transformations have finished. The eager notification is ignored.
eager andnotification_url andeager_notification_url andeager_async - The upload method response and the notification_url are sent after the upload completes and include a batch_id for tracking the eager job. - eager_notification_url is sent after the eager transformations have finished with a batch_id for tracking.

Eager notification response

When the eager transformations are completed, an HTTP POST request will be sent to the eager notification URL you provided with details about the requested eager transformations including the HTTP and HTTPS URLs for accessing the derived images. For example:

If the eager transformation is not generated for some reason then the notification response will include a status: failed and the reason, for example:

Verifying notification signatures

Cloudinary signs all notification responses that it sends to your provided notification_url or eager_notification_url endpoint, allowing you to validate that they were not sent by a third-party. The notification includes both an X-Cld-Signature header and a X-Cld-Timestamp header for validating the notification response.

When you provide a notification_url or eager_notification_url endpoint in a method request, or if you set a global notification_url in the Console Settings, Cloudinary includes both an X-Cld-Signature header and a X-Cld-Timestamp header with the response sent to the specified notification endpoint.

Here's an example POST request header sent by Cloudinary:

The signature is a hexadecimal message digest (hash value) created with the SHA-1 or SHA-256 (Secure Hash Algorithm) cryptographic function.

Note
By default, Cloudinary supports both SHA-1 and SHA-256 digests for validation, and you can use either. The SDK methods use the SHA-1 algorithm by default, but you can use the SHA-256 algorithm instead by setting the signature_algorithm SDK configuration parameter to sha256. If you want to limit your account to allow only the SHA-256 digest for all your validations, submit a request.

Use the Cloudinary SDK's verify_notification_signature method to verify the signature in the notification, and how many seconds it is valid for.

Alternatively, you can manually compare the returned signature value in the header with the value of a signature generated on your server side as follows:

  1. Create a single string containing the entire response body
  2. Append the X-Cld-Timestamp value on the end of the string.
  3. Append your API secret to the end of the string. (See the note below).
  4. Create a hexadecimal message digest (hash value) of the string using an SHA function.

Note
The response sent to your notification URL will also include the api_key that requested the notification. This is important where you use multiple key/secret pairs with your product environment, as you need to verify the signature using the corresponding api_secret.

For example, if the response body is {public_id: 'sample'}, the X-Cld-Timestamp is 1315060510, and your API secret is abcd:

  • Parameters to sign:
    • {public_id: 'sample'}
    • 1315060510
  • In a single string:
    • {public_id: 'sample'}1315060510
  • String including the API secret that is used to create the SHA-1 signature:
    • {public_id: 'sample'}1315060510abcd
  • SHA-1 hexadecimal result:
    • 25f7e91709c858b97d688ce8da799dedb290d9ef

Tip
You should also compare the timestamp value with the current time to make sure that the signature was generated within a reasonable amount of time (e.g., within the last 2 hours).

PHP code example for validating the notification:

See also
Have a look at the Cloudinary Signatures quick reference for a summary of the payload string to sign for notification signatures as well as information on other use cases that may require signature generation.

Notification response examples

Important
Cloudinary may add more fields to API responses and notifications in the future, so please ensure that your response parsing remains backwards compatible and wont be broken by the presence of unknown fields.

This section provides several examples of notifcation responses to a variety of different API calls or Media Library operations. Keep in mind that this list is not comprehensive, and that the exact content of the response will depend on the options sent with the relevant API call or the exact operation performed in the Media Library.

Tip
The notification responses include a notification_context with information on the time the original request was triggered and the source of that request - either an email address for a UI initiated request, or the api_key of an API method call.

Tags

Context

Metadata

Rename

(Change the public ID)

Change display name

Supported only for product environments using dynamic folder mode.

Create folder

Move between asset folders

Supported only for product environments using dynamic folder mode.

Delete

Sprite generation

Multi generation

Explode

Create collage

Upload (simple)

Upload (complex)

Access control

✔️ Feedback sent!

Rate this page: