POST requests to your configured endpoint when a generation task is created, starts running, completes, fails, or is canceled.
Webhook delivery is at least once. Your handler must verify the signature, reject replayed requests, and process events idempotently.
Configure Endpoints
Configure webhook endpoints from the developer dashboard: https://skills.video/dashboard/developer Use the dashboard to manage endpoint URLs, event filters, enablement, test deliveries, and secret rotation. Store the signing secret in server-side secret storage when it is shown. Do not place the webhook secret in frontend code, mobile apps, logs, or public repositories. Each endpoint is scoped to a workspace and event filter. It only receives events for the selected workspace and selected task lifecycle events.When Webhooks Are Sent
Webhooks are emitted for generation tasks created through:Event Types
Supported event types:
Terminal events are
task.completed, task.failed, and task.canceled. Once your local task record reaches a terminal state, do not let an older non-terminal event move it backward.
Webhook event names describe lifecycle transitions. prediction.state and prediction.status describe the current task state in the payload.
Use the event name to decide which handler branch to run. Use
prediction.state to update your local task record.
Delivery Format
Your endpoint receives an HTTPPOST request with a JSON body.
Example body:
task.failed, prediction.error contains a sanitized error object with code and message. Raw provider errors and internal error details are not included. For task.completed, generated media is usually available in prediction.artifacts and, depending on the model, task output fields returned by the generation result endpoint.
Failed task example:
Payload Field Reference
Common fields:
Artifact fields vary by model and media type, but commonly include
documentId, state, type, provider, model, prompt, actual_prompt, resolution, aspect_ratio, url, and asset.
Signature Algorithm
Each webhook endpoint has a secret. Store it on your server and use it to verify every incoming webhook before parsing or processing the JSON payload. New integrations should use the Standard Webhooks v2 headers. Legacy v1X-Webhook-* headers are still sent for backward compatibility with existing receivers.
Standard Webhooks v2
skills.video sends Standard Webhooks-compatible headers:standardwebhooks verifier checks the timestamp tolerance and compares signatures safely. Your route still needs the raw body; do not mount a JSON parser before the webhook route.
Java / Spring Boot Verification
This example verifies Standard Webhooks v2 with JDK crypto APIs. Keep the body as raw bytes and parse JSON only after verification succeeds.Legacy v1 Compatibility
The signature is computed from the timestamp and the exact raw request body:- Use the value of
X-Webhook-Timestampexactly as received. - Use the raw request body exactly as received. Do not verify against parsed and re-serialized JSON.
- Use HMAC-SHA256 with the endpoint secret as the HMAC key.
- Compare signatures with a constant-time comparison function.
- Reject requests whose timestamp is outside a short tolerance window, such as 5 minutes.
- Verify the signature before trusting
X-Webhook-Event-Id,X-Webhook-Event-Type, or any body fields.
Legacy v1 Node.js Verification
This example verifies the signature and timestamp. Mount the raw body parser before any JSON parser for the webhook route.Python Verification
Signature Test Vector
Use this fixed example to verify your implementation. The exactraw_body string matters.
timestamp + "." + raw_body, and the expected legacy signature for the same example is:
Signature Troubleshooting
Most signature failures come from verifying different bytes than the bytes that were signed.
Log enough metadata to debug failures, but never log the webhook secret, full API keys, or sensitive user input.
Replay Protection
Signature verification proves the request was signed with the endpoint secret, but a valid signed request can still be replayed for a short period. Combine timestamp checks with event id deduplication. Recommended checks:- Reject requests with missing or invalid signature headers.
- Reject requests whose
webhook-timestampis outside your tolerance window, such as 5 minutes. - Insert
webhook-idinto a table with a unique constraint before doing any business work. - If the insert conflicts, treat the event as already received and return
2xx.
webhook-id as the replay and idempotency key. Legacy receivers can use X-Webhook-Timestamp and X-Webhook-Event-Id, which carry the same values.
Keep event ids for at least the full retry window. A 24-hour retention period is a practical minimum for most integrations.
Idempotency
Webhook delivery uses an at-least-once model. Your endpoint must assume these cases can happen:- The same event is delivered more than once.
- A delivery succeeds in your system, but the HTTP response is lost and skills.video retries.
- Events for the same task arrive out of order because older deliveries are retried later.
- A terminal event is processed before an older
task.createdortask.startedretry.
Recommended Tables
Processing Flow
- Read the raw request body.
- Verify
webhook-signatureandwebhook-timestamp. - Parse the JSON body.
- Insert
webhook-idintoskills_video_webhook_events. - If the insert conflicts, return
204 No Content. - Upsert your local task record by
prediction.id. - Apply terminal-state protection so older non-terminal events do not overwrite a completed, failed, or canceled task.
- Before executing any side effect, insert
(prediction.id, action)intoskills_video_task_side_effects. - Only run the side effect if that insert succeeds.
- Return a
2xxresponse quickly.
Responses And Retries
Return any2xx status code to acknowledge delivery. 204 No Content is recommended.
Non-2xx responses, network failures, and timeouts are retried.
Recommended response behavior:
Do not wait for long downloads, media processing, or downstream API calls before responding. Enqueue that work and return
2xx after the event has been durably recorded.
Test Events
Webhook endpoint test deliveries use the same signature headers. Test events have:204 after signature verification.
Delivery Logs
Use the developer dashboard to inspect the 20 most recent delivery attempts for a webhook endpoint: https://skills.video/dashboard/developer Delivery log entries contain fields like this:success means your endpoint returned a 2xx response. failed means the delivery exhausted retries or could not be queued. pending means it is waiting for its next attempt. processing means a worker has claimed the delivery.
Create Request Idempotency
Webhook idempotency is supported throughwebhook-id on delivered events. Legacy receivers can use the equivalent X-Webhook-Event-Id. Do not rely on Idempotency-Key for generation create requests unless your integration has confirmed support for that header.
If your client retries POST /api/v1/generation/..., store the first returned task id and reconcile by that id before retrying from your own backend. This prevents your application from creating duplicate jobs when the first request succeeded but the client connection failed.
Implementation Checklist
- Configure one endpoint per destination URL and workspace in the developer dashboard.
- Store the endpoint secret in server-side secret storage.
- Verify Standard Webhooks v2 signatures with
webhook_id + "." + timestamp + "." + raw_body. - Reject timestamps outside your replay window.
- Insert
webhook-idbefore running business logic. - Guard terminal task states from older non-terminal retries.
- Make side effects idempotent with
prediction.id + action. - Return
2xxafter durable receipt and process slow work asynchronously. - Use delivery logs to inspect failed attempts and retry timing.
Security Checklist
- Accept only
POSTrequests. - Accept only
Content-Type: application/json. - Verify signatures before parsing JSON or executing business logic.
- Enforce a timestamp tolerance window.
- Deduplicate by
webhook-id. - Make task-level side effects idempotent.
- Put a maximum raw body size on the webhook route.
- Store webhook secrets only in server-side secret storage.
- Do not log webhook secrets, full signatures, API keys, or sensitive user payloads.
- Rotate the webhook secret immediately if exposure is suspected.