HeyGen twins take 10-20 min: how do Sume avatar jobs show progress?

Short answer

HeyGen's avatar page says digital twins are typically ready in 10 to 20 minutes and stock avatars are available immediately. Sume's documentation gives no ready-in time for an avatar or a video. Instead every request creates a job, and you poll its status or ask for a webhook. Build your flow around the job state, not around a number of minutes.

The HeyGen figures and the Sume contract

The two sides describe waiting differently. HeyGen gives a typical range for its digital twin. Sume documents the mechanism.

How a Sume avatar request flows

You POST to /v1/avatar-1.0/generate with a top-level avatar_handle and an input union. You send an Idempotency-Key so a retry does not create a second avatar. You then poll the job until it is completed and fetch the result, which returns the avatar handle or resource id for video generation. The same pattern applies to the talking-video route.

• Poll /v1/jobs/{id}/status for state.
• Fetch /v1/jobs/{id}/events for progress detail.
• Fetch /v1/jobs/{id}/result when completed.
• Or use the webhook communication mode instead of polling.

Planning without a fixed time

If your product shows a progress screen to a user, do not promise a time. Show the job state and update it when the status changes. If you run batch work, submit all the jobs first and then poll them in a loop with a delay between checks; do not submit a video before its avatar job completes, because the video needs a ready avatar. For long runs, the webhook mode removes the need to poll at all. Details of those modes are in the jobs and results documentation.

Cost of the wait

Avatar creation is a flat $0.95, and video is $0.184, $0.245 or $0.55 per second by tier. Check the job result before you assume success. If you are testing a pipeline, a 4-second clip at standard is 4 x $0.184 = $0.74, which is the cheapest valid video job. Use it to test the full loop, from create to result, before you queue real work.

Use the Idempotency-Key header on every create call. The Sume docs tell you to submit requests with an Idempotency-Key. If a network error leaves you unsure whether the request arrived, resending with the same key is the pattern the docs intend, rather than inventing a new key for the same avatar. Pick keys that mean something in your system, such as the brand and the avatar name, so a retry from a different worker still matches.

Store the returned avatar handle in your own database next to the brand it belongs to. The handle is what later talking-video requests use, so losing it means listing avatars again with GET /v1/avatar-1.0/avatars. That route exists to read what you have already created.