Video Router sync waits 30 seconds; your Seedance 2.5 clip keeps going

Setting mode to sync on POST /v1/video-router/generate does not wait for the video. It blocks the HTTP request for at most wait_timeout_seconds (the maximum is 30), and if the job is not finished by then you still get a 2xx response with the current queued or processing state. A seedance-2.5 clip of 12 seconds or more routinely outlasts that budget, so treat sync as a convenience for short jobs, not a way to avoid polling.

This is stated in the Sume API reference: video, avatar-video and face-swap jobs routinely outlast the wait, and the guidance is to continue with status_url, honor next_poll_after_seconds, and never submit a second paid job for the same intent.

The four modes

The OpenAPI schema for the Video Router request lists async, sync, subscribe and webhook. Every mode returns the job id in the first response.

Webhook mode details

webhook_url must be public HTTPS; localhost, private-network and non-HTTPS URLs are rejected. Sending a webhook_url without an explicit mode selects webhook. Delivery is terminal-only, meaning job.completed, job.failed and job.canceled, with no progress callbacks, so keep status polling available as a backup.

Note the field names differ by route. The Video Router schema uses webhook_url, while the /v1/videos route documents callback_url in its request table. Keep each integration on one route so you do not mix them up.

What to do after the wait

A sync response that is not yet terminal carries the current job state with polling URLs. The Video generation docs suggest a polling interval around 30 seconds and note that video generation typically takes 30 seconds to several minutes depending on the model and parameters. Honor next_poll_after_seconds when it is present and stop polling when the job reaches completed, failed or cancelled.

Capacity matters too. If the API process has no waiter capacity, the sync request still returns 2xx with the current state, so code that assumed it always blocked for the full budget will see an immediate answer under load. Either way the job is real, billed on its own terms, and still running; resubmitting would create a second paid job for the same intent.

A safe sync call

Use a short wait, an Idempotency-Key so a retried submit returns the original job, and treat any non-terminal answer as a cue to poll rather than to re-send.

``bash curl -X POST https://api.sume.com/v1/video-router/generate \ -H "Authorization: Bearer $SUME_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: seedance-sync-001" \ -d '{ "model": "seedance-2.5", "prompt": "A vertical product clip on a desk, natural light", "resolution": "720p", "duration": 12, "aspect_ratio": "9:16", "mode": "sync", "wait_timeout_seconds": 20 }' ``

If the answer is still queued or processing after 20 seconds, that is normal for this clip. Read status_url from the body and poll it. The idempotency header makes a retry safe, because a replay returns the original job.

Why this matters for the Seedance 2.5 era

Seedance 2.5 raised the ceiling to 30 seconds per generation on Sume, and the longer the clip, the less likely any 30-second blocking call sees a finished file. Default to async or webhook for seedance-2.5 and wan-3.0, and reserve sync for short checks on small clips.