Callback or polling for Omni 4K jobs on the Sume video API

For a batch of Omni 4K jobs, use a webhook and keep a slow poll as the fallback. A webhook sends one signed request when a job ends, while polling spends many requests per job on in_progress. For a single 360p draft you are watching, polling is simpler.

Sume gives you both on the video API. POST /v1/videos takes callback_url, which must be HTTPS, and Sume POSTs to it when the job reaches a terminal state. The Video Router and other model routes take mode: "webhook" with webhook_url (Video generation page, Webhooks).

Polling versus webhook

What arrives

Sume sends terminal events only: job.completed, job.failed and job.canceled. There are no progress events. On /v1/videos, the payload is Sume's standard job webhook envelope, not the OpenRouter one. The request is signed: Sume signs the raw JSON body and sends x-sume-webhook-timestamp and x-sume-webhook-signature headers. Verify the signature on the raw body before you act, and refuse to run at all if your secret is empty.

Submit with a callback

The 4K price of a ten-second clip is $3.75, so a missed delivery is worth catching. Send callback_url with the job and keep the job id in your own record.

curl -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: final-4k-017" \
  -d '{
    "model": "gemini-omni-flash-1.1",
    "prompt": "Rotating perfume bottle on black glass, soft rim light",
    "resolution": "4K",
    "duration": 10,
    "aspect_ratio": "16:9",
    "callback_url": "https://example.com/hooks/sume"
  }'

Keep a poll beside it

A webhook can fail on your side: the endpoint was down, a deploy was in progress, a firewall dropped the call. Keep a slow poll that checks any job older than a few minutes that has no recorded result, as Jobs and results recommends for the poll fallback beside a webhook. For a 4K job the poll can be every 30 seconds, because the answer is rarely early.

A rule for the endpoint

The callback endpoint should do as little as possible: check the signature and timestamp, write the job id and status to your store, return 200, and process the result later. A slow handler invites a retry, and a retry is a duplicate event for the same job. Make your store key the job id, so a second delivery overwrites the first without effect.

Worked example: 60 finals

Take 60 ten-second 4K finals, $225.00 in all at $3.75 each. Polling every 10 seconds for a job that takes several minutes costs dozens of requests per job, and across 60 jobs that is thousands of requests and a rate-limit risk, since Sume answers 429 rate_limited when you go over your budget. With callbacks it is 60 inbound requests, one per job, and a slow reconciliation poll of every 30 to 60 seconds for any job without a recorded result.

Because the balance is reserved on submit at the billable rate, 60 finals at 4K need $225.00 free at once to submit them all together. If you submit in waves of ten, each wave needs $37.50, and a callback is a natural trigger to submit the next wave when a job finishes.

Security notes

A callback URL is an open door unless you check what comes through it. Verify the signature header against the raw request body with your secret, reject a missing or empty secret at startup so the check can never silently pass, and compare timestamps to refuse old deliveries. Sume rejects localhost, private-network and non-HTTPS callback URLs, so test with a tunnel that gives you a public HTTPS address.

Choose by batch size

• 1 to 5 jobs: poll with a backoff, no server needed.
• Dozens of jobs or a long queue: webhook, because each job is one inbound request.
• Production: webhook plus a reconciliation poll.
• Any size: a unique Idempotency-Key per job so retries cannot double-bill.