Configuring Endpoints:

Webhook endpoints are configured in the Crunch dashboard under Settings.

Enter a URL from your application that Crunch will call for event notifications.

Webhooks vs. polling:

Please use webhooks to track asset status rather than polling the Job Status API .

Webhooks are much more efficient for both you and Crunch, and we rate limit GET requests to the /video/job/:asset_id endpoint, which means polling the /video/job/:asset_id API doesn't scale.

Receiving Events:

Crunch uses webhooks to notify your application about things that happen asynchronously, apart from the API request-response cycle. For example, you may want to update something on your end when a video asset status changes from PENDING to PREPROCESSING to TRANSCODING to COMPLETED or FAILED. When these asynchronous events happen, Crunch will make a POST request to the address you give us and you can make changes with it on your end.

Webhooks can be configured here using a webhook endpoint URL trigger. Once the webhook is configured, a notification will be sent for each event.

Currently, Crunch supports the following two events in webhook:

Success event:

Error event:


Types of Events

Status Events

PENDINGThe job is enqueued and will be picked up for processing soon.
PREPROCESSINGPreprocessing is the stage of a job that takes place prior to the main transcoding.
TRANSCODINGThe job is being processed or getting transcoded.
COMPLETEDJob is completed successfully without any error.
FAILEDThe job has failed. For additional information, see failure message in get job status.

Livestreaming API Events

Following are the events which are given in Video APIs Livestreaming API

PENDINGLive stream session is created but waiting for resources to get provisioned.
PROVISIONINGLive stream session is created and necessary resources are getting provisioned.
- Resources are provisioned and a slot is getting allocated for the live stream session.

- In case of Error, unable to provide a slot for the live stream session. In this case user may have to retry creating a new live stream session.
READYResources are allocated and server is ready to accept the live stream feed for streaming.
RUNNINGClient is broadcasting to our server and the video live streaming is running currently.

End user will be able to consume the live feed through any supported players.
STOPPINGEither client is disconnected (or) stopped broadcasting. The live stream will be waiting for the configured time to reconnect if client decides to reconnect later.

Note: Server will accept broadcasting,even when session is in STOPPING state.
IDLEThe live stream session is not used atleast once for the configured idle time, the live stream session will move to IDLE state before moving to the TERMINATED state.

Note: Server will accept broadcasting,even when session is in IDLE state.
- Either client is disconnected (or) stopped broadcasting and reconnection not happened after configured time. Then slot will be freed and resources will be released for next live stream session.

- Live stream session is in READY state and client is not broadcasting any data to the server for the configured time. Then the resources will be release for next live stream session.

- Live stream session is in RUNNING state and due to some unfortunate events from our media server side and the session will be moved to ERROR state.

  •     Access Tokens
  • Video APIs