Retrain a cloned voice without breaking old videos
HeyGen keeps a voice ID when a clone is retrained. On Sume, an avatar is referenced by a stable handle, and each text-to-speech job records its voice and model.

On Sume, an avatar is referenced by its avatar_handle, so videos you already made keep working and new requests keep using the same handle. For voice continuity, read the voice, model_id and settings that each text-to-speech job records, and reuse them for the next line. The docs read here describe no retrain operation.
What HeyGen's release says
The HeyGen September 2026 release page says retraining a professional voice clone preserves the voice ID, name, language and slot. If retraining fails, it falls back to the previous voice, and deleting a voice frees the slot. The practical point is a stable identifier for downstream work.
Sume's stable identifier: the handle
POST /v1/avatar-1.0/generate creates an avatar under a top-level avatar_handle, stored without a leading @. Later POST /v1/avatar-1.0/talking-video requests refer to the ready avatar by that handle. The Avatar docs describe creating from a prompt, structured traits or a photo; they do not describe retraining an existing avatar, so a changed identity means a new avatar under a new handle.
Keeping a voice consistent
A completed text-to-speech job (text_to_speech) records how its audio was made: model_id, voice ({"mode": "id", "id": "..."}), language, output_format, and the settings it used, generation_config and speed. Each setting is null when the request did not send it. The jobs docs say to read these from the job to make the next line sound the same.
| Record | Why |
|---|---|
avatar_handle | Reference the same avatar in later requests |
TTS model_id and voice.id | Reproduce the same voice for the next line |
language, speed, generation_config | Reproduce the same delivery |
| Job id of each render | Re-read results without resubmitting |
A change plan that does not touch old videos
Completed jobs and their media.sume.com artifacts stay readable by job id, so a new avatar or voice never rewrites a finished video. When you change identity, give it a new handle or version suffix such as presenter_v2, run a short test video with the new handle, and move your pipeline over only after you approve the result. Keep the old handle until nothing references it.
A job is tied to its workspace and creating member, so record which key made it. See Jobs and results.
Sources
Related posts
More in Developers
- Retry a failed image batch on Sume: not billed, same Idempotency-Key
On Sume a failed image generation is not billed, but a retry after a timeout can double-submit. Send an Idempotency-Key per image and retry only the submit.
- Retry hints in the body or a header: reading Sume's Retry-After
Notion repeats Retry-After in response bodies. Sume can send a retry-after header on 429s. Here is how to retry each Sume error code safely.
- Retry-on-timeout wrapper from the Sora days? Add an idempotency key
A wrapper that retries a video submit on timeout can create two paid Sume jobs. Build an Idempotency-Key from the request, and learn what a replay returns.
- Retry policy by Sume job error category
Sume failed jobs carry a category and retryability. Retry queue and capacity errors with a cap, stop on validation and quota, and skip blanket retries.
Written by Sume