Video webhooks
The HTTP calls a video platform makes to your server the moment something happens — a video finished encoding, a live stream went on air — so your product reacts without polling.
A webhook is the video platform calling your backend when an event happens — encoding finished, stream started — so you publish, notify or update records instantly; viewer actions such as finishing a video come from player events instead.
What are video webhooks?
A webhook is an HTTP request a platform sends to a URL you register whenever a particular event happens. For video, those events are things that take time or happen on their own schedule: an upload finishes transcodingTranscodingRe-encoding a source video into multiple resolutions and bitrates so a player can switch between quality levels on the fly.Open definition →, a live streamLive streamReal-time video delivered as it is captured, transcoded and segmented on the fly — webinars, events, broadcasts.Open definition → connects or ends, a recording becomes available. The request carries a JSON payload describing what changed.
The alternative is polling — asking the video APIVideo APIUpload, transcode, store, protect and stream video through HTTP calls — the infrastructure under a product’s video feature, without building it.Open definition → every few seconds whether the video is ready yet. Polling wastes requests, adds delay and runs into rate limits. Webhooks invert it: the platform tells you once, at the right moment.
What teams automate with webhooks
| Event | What your backend does |
|---|---|
| Video processing status changes | Publish the lesson, notify the uploader, unlock the product page |
| Live stream created | Add the event to a schedule, send invitations |
| Live stream connected | Mark the event “on air”, open the chat, alert subscribers |
| Live stream disconnected | Show a “we’ll be right back” state, page the producer |
| Live stream finished | Close the chat, queue the recording for publishing |
| Live stream cancelled | Notify registrants, free the slot |
Webhooks vs player events
Webhooks describe what happens on the platform. What a viewer does — starts, pauses, reaches the end — happens in the player, in their browser or app. To record that a user finished a video, or to sync course progress with an LMS, listen to player events and send them to your backend yourself:
Embed the player through its JavaScript or native SDK rather than a bare iframe.
Listen for progress (time updates) and completion (ended) for the signed-in user.
Send user, video and position to your own endpoint, throttled — for example every 10 seconds and on completion.
Your server writes progress to the database or LMS, and can resume playback from the last position next time.
Handling webhooks safely
- Authenticate the sender. Accept webhook calls only with credentials you configured — basic auth on the endpoint, a shared secret or a signature — so nobody can fake a “video ready” event.
- Answer fast, work later. Return 2xx immediately and do slow work in a queue; a timeout may be treated as a failure and retried.
- Make handlers idempotent. The same event can arrive twice. Key your processing on the video or event ID so a repeat changes nothing.
- Don’t trust order. Events can arrive out of sequence; read the status in the payload rather than assuming the previous step happened.
Further reading
- Kinescope webhook types — payloads for each event.
- Basic auth for webhooks — protecting your endpoint.
- Kinescope developer hub — try player events in the live IFrame Player API demo.
