Synthesia says 3 to 5 minutes per video; how to watch a Sume job
Synthesia's quickstart says videos usually finish in 3 to 5 minutes. Sume avatar jobs run async; read status, then the events endpoint for a slow render.
Synthesia's API overview says video processing typically takes 3 to 5 minutes before status becomes complete and a time-limited download link appears. Sume does not publish a fixed render time for avatar video, and the quality tier changes it: standard is the fastest path, max is slower. The practical answer is the same on both: submit, store the id, and let a webhook or a calm poll tell you when it is done. On Sume you can also read GET /v1/jobs/{id}/events to see why a render is slow.
Synthesia facts: API overview, read 2026-10-04.
What the two vendors tell you
Synthesia names a typical range and says to poll the retrieve endpoint or configure a webhook for completion. Sume's avatar video page shows three reads on a job: status, events and result.
| Item | Synthesia | Sume |
|---|---|---|
| Stated duration | Typically 3 to 5 minutes | Not stated; varies by quality tier |
| Poll | Retrieve a video | GET /v1/jobs/{id}/status |
| Debug a slow job | Not described on the page read | GET /v1/jobs/{id}/events |
| Completion push | Webhook | mode: webhook with a public HTTPS webhook_url |
| Output link | Time-limited download link | Public media.sume.com artifacts in the result |
A polling shape that does not hammer the API
Start at a few seconds, back off, and stop when the job is terminal. Poll from your server and push the result to the client. If you want push, use a webhook and keep one slow poll as a safety net, as the jobs guide advises.
import os
import time
import requests
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
def wait(job_id, every=10, limit=900):
waited = 0
while waited < limit:
url = f"https://api.sume.com/v1/jobs/{job_id}/status"
data = requests.get(url, headers=H, timeout=30).json()["data"]
print(data["sume_status"])
if data["terminal"]:
return data
time.sleep(every)
waited += every
return NoneWhen a render is slow
Read the events endpoint before you resubmit. A slow job that is still moving through its stages is not a failed job, and a second submit under a new key would pay twice. Resubmit only after a terminal failure, and reuse the same Idempotency-Key for a true retry of the same request.
- Queued: the job is waiting for capacity.
- Processing: stages are advancing; read events.
- Failed: read the public error before retrying.
Bottom line
Treat 3 to 5 minutes as a planning figure for Synthesia only, because it is the vendor's own statement. For Sume, design the waiting experience around async jobs and a webhook, and use the events endpoint when a customer asks why a clip is not ready yet.
Sources
Related posts
More in Developers
- Hourly synthetic monitor for an image API on a cheap Sume model
A scheduled script that makes one real image call, checks status, URL and latency, and exits non-zero on failure. Budget it from the endpoint's cost_usd.
- End-user id on jobs: OpenAI safety identifier vs Sume metadata
OpenAI's Realtime guide asks for an OpenAI-Safety-Identifier header. Sume stores caller metadata on the job but does not send it to the provider. Use both.
- Temporal Paygo starter: submit and poll a Sume job
Temporal's Paygo plan has a $0 monthly minimum. A first workflow can submit a Sume job in one Activity and poll its status in a second. Python code included.
- Test a faster-and-cheaper claim with your own timings and usage.cost
Luma's news page says Ray3.14 is 4x faster and 3x cheaper. A short Python script turns your own job timings and usage.cost values into two ratios you can trust.
Written by Sume