Skip to main content
Webhooks let your backend react to generation task updates without polling. skills.video sends signed 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:
Each webhook endpoint is scoped to a workspace. It only receives events for tasks in that workspace and only for event types enabled on that endpoint.

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 HTTP POST request with a JSON body.
Headers: Example body:
For 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 v1 X-Webhook-* headers are still sent for backward compatibility with existing receivers.

Standard Webhooks v2

skills.video sends Standard Webhooks-compatible headers:
The v2 signature is computed from the event id, timestamp, and exact raw request body:
Use the official verifier when possible:
Express example:
The 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:
Important details:
  • Use the value of X-Webhook-Timestamp exactly 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 exact raw_body string matters.
Standard Webhooks v2 signed payload:
Expected Standard Webhooks v2 signature:
Legacy v1 is also sent for existing receivers. Its signed payload is timestamp + "." + raw_body, and the expected legacy signature for the same example is:
Node.js check:
Java check:

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:
  1. Reject requests with missing or invalid signature headers.
  2. Reject requests whose webhook-timestamp is outside your tolerance window, such as 5 minutes.
  3. Insert webhook-id into a table with a unique constraint before doing any business work.
  4. If the insert conflicts, treat the event as already received and return 2xx.
Webhook deliveries do not include a separate nonce header. Use the timestamp to limit signature lifetime and use 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.created or task.started retry.
Use two layers of idempotency:

Processing Flow

  1. Read the raw request body.
  2. Verify webhook-signature and webhook-timestamp.
  3. Parse the JSON body.
  4. Insert webhook-id into skills_video_webhook_events.
  5. If the insert conflicts, return 204 No Content.
  6. Upsert your local task record by prediction.id.
  7. Apply terminal-state protection so older non-terminal events do not overwrite a completed, failed, or canceled task.
  8. Before executing any side effect, insert (prediction.id, action) into skills_video_task_side_effects.
  9. Only run the side effect if that insert succeeds.
  10. Return a 2xx response quickly.
Terminal-state protection example:
Side-effect idempotency example:

Responses And Retries

Return any 2xx 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:
Your handler can either store test events separately or return 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:
Delivery fields: 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 through webhook-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-id before running business logic.
  • Guard terminal task states from older non-terminal retries.
  • Make side effects idempotent with prediction.id + action.
  • Return 2xx after durable receipt and process slow work asynchronously.
  • Use delivery logs to inspect failed attempts and retry timing.

Security Checklist

  • Accept only POST requests.
  • 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.