callback_url or webhook_url? Which Sume route takes which field name

POST /v1/videos takes callback_url; the model endpoints take mode webhook with webhook_url. Both must be public HTTPS and both deliver signed job events.

5 min readSume
All posts

On POST /v1/videos the field is callback_url, and the URL must be HTTPS. On the model endpoints under /v1/models/... and routes like /v1/avatar-1.0/generate, you send mode: "webhook" together with webhook_url. The two names are not interchangeable, so a port from one surface to the other needs a rename.

The two surfaces side by side

Both end in the same place: a signed POST of the standard Sume job envelope, with job.completed, job.failed or job.canceled. The signature scheme is the same too, so one verifier handles both. The OpenRouter video.generation.* events and X-OpenRouter-Signature header are not used.

Webhook request fields by route, from the Sume docs (read 2026-10-08)
RouteFieldExtra fieldURL rule
POST /v1/videoscallback_urlnonemust be HTTPS
POST /v1/models/... and model endpointswebhook_urlmode: "webhook"public HTTPS; localhost and private networks are rejected
Action, Format or Agent run endpointssee run webhooks-events are *.run.terminal

Request body for the video route

A minimal body for the video route looks like this. Nothing else changes: the 202 response still returns id, polling_url, status and model, so a poll can run alongside the callback as a backup.

{
  "model": "wan-3.0",
  "prompt": "A paper boat on a rainy street, slow dolly in",
  "duration": 5,
  "resolution": "720p",
  "aspect_ratio": "9:16",
  "callback_url": "https://hooks.example.com/sume/video"
}

Rules shared by both

Sume sends terminal events only. There are no progress or partial deliveries. The receiver should return any 2xx after it stores the event durably. Sume retries network errors and non-2xx answers up to 10 attempts total, with a 30-second default delay and a 10-second timeout per attempt.

Use job_id as the idempotency key on your side. If all attempts fail, the job still reached its real terminal state; POST /v1/jobs/{job_id}/webhook/redeliver (needs jobs:write) re-sends it with a fresh timestamp and signature.

  • Local development: use a public HTTPS tunnel, because localhost is refused on the job endpoints.
  • Send test (POST /v1/webhooks/test-deliveries, account:write) posts a dummy webhook.test body and never replays a real job.

One receiver for both

Because the signature scheme and the event names are shared, a single endpoint can serve a mixed workload, such as video jobs submitted with callback_url and image or avatar jobs submitted with webhook_url. Route on the event value and never assume a body shape. Treat an event you do not know as a 204, so a new event type does not turn into a retry storm.

The payload of a successful job holds payload.artifacts, a list of objects with id, url, type and content_type. A failed or canceled job uses status: "ERROR" and an error object instead, so branch on event, not on status alone. If you only submitted video jobs, the same job is also readable at GET /v1/jobs/{id}/result, which is the safe fallback when a delivery never arrives.

Further reading

See what the callback_url envelope contains and the delivery status values.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume