API API Documentation

Welcome to's official documentation portal.In here, you'll find everything you need to:

Get up and running with's public API 🤙
Leverage powerful features like Webhooks and Custom Actions 🚀
Build your own OAuth2.0 app 🚢

Get Started    Guides

Webhooks Overview

This page describes the basics and technical details of Webhooks. For help creating a Webhook workflow with the Zapier app, please see our introductory Zapier guide.

Example Application

If you'd like to build your own consumer for Webhooks, feel free to grab and extend our Example App on Github.


Webhooks provide a way to leverage events that occur inside of into notifications that can be sent to external systems for processing, API callback, and ultimately, workflow automation.


Webhooks can be configured in the Webhooks area of Developer. A Webhook requires:

  • Name — Will be shown in Developer only.
  • URL — Where to deliver events.
  • Team — Which team this action will be installed on.
  • Events — Which event, or events, should trigger the Webhook.

Supported events

A single Webhook can subscribe to any number of the following events:


Sent when


A new Project is created.


A Project's settings are updated.


A Project is deleted.


Sent when


An Asset is added/created in and transcoding starts.


An Asset's description, name, or other file information is changed.


An Asset is deleted (manually or otherwise).


All transcodes are complete after an Asset is uploaded.


An Asset's status label is set, changed, or removed.


Sent when


A new Comment or Reply is created.


A Comment is edited.


A Comment is deleted.

Review Links

Sent when


A new Review Link is created.

Payload delivers a JSON payload to the specified webhook endpoint. Here's an example payload for an asset.created event.

  "type": "asset.created",
  "resource": {
    "type": "asset",
    "id": "<asset-id>"
  "user": {
    "id": "<user-id>"
  "team": {
    "id": "<team-id>"

All payloads contain a type field, indicating the type of event occurring, as well as a resource object. The resource object specifies the type and id of the resource related to this event.

In the above example of an asset.created event, this would be the id newly created Asset. Additionally, user and team objects are included. These reference the User who triggered the event, and the Team context for the resource.

Aside from the immediate User and Team context, we do not include any additional information about the subscribed resource. If your application requires additional information or context, we recommend using our HTTP API to make follow-up requests.


By default, all Webhooks are provided with a signing key. This is not configurable. This key can be used to verify that the request originates from


Included in the POST request are the following headers:



The time of Webhook delivery.


The computed signature.

The timestamp is the time of delivery from's systems. This can be used to prevent replay attacks. We recommended verifying this time is within 5 minutes of local time.

The signature is a HMAC SHA256 hash using the signing key provided when the Webhook is first created.

This is how you can go about verifying the signature:

  1. Extract the signature from the HTTP headers
  2. Create a message to sign by combining the version, delivery time, and request body
    • v0:timestamp:body
  3. Compute the HMAC SHA256 signature using your signing secret.
    • Note: The provided signature is prefixed with v0=. Currently only has this one version for signing requests. You will need to add this prefix to your computed signature.
  4. Compare!

Updated 11 months ago

Webhooks Overview

This page describes the basics and technical details of Webhooks. For help creating a Webhook workflow with the Zapier app, please see our introductory Zapier guide.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.