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 .
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
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:
Types of Events
|The job is enqueued and will be picked up for processing soon.|
|Preprocessing is the stage of a job that takes place prior to the main transcoding.|
|The job is being processed or getting transcoded.|
|Job is completed successfully without any error.|
|The 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
|Live stream session is created but waiting for resources to get provisioned.|
|Live 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.
|Resources are allocated and server is ready to accept the live stream feed for streaming.|
|Client 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.
|Either 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.
|The 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.