What to log for a likeness consent trail: five fields per request
Sume avatar and face swap requests carry an avatar_handle, a source URL, a quality, an Idempotency-Key and a job id. Log those five with the consent record.
When you use a real person's face with Sume's avatar or face swap APIs, keep five things next to the person's written consent: the avatar_handle, the source image or video URL, the quality value, the Idempotency-Key and the job id. Sume's documentation for these routes describes those fields; it does not describe a consent-capture step, so the record has to be yours.
The five fields
Each field answers one question in a later dispute: which face, from which file, rendered how, by which call, and which job produced the output.
| Field | Where it appears | What it proves |
|---|---|---|
| avatar_handle | Avatar create, talking video, face swap, fabric | Which identity the output used |
| image_url or video_url | Avatar photo input, face swap source | Which source file you submitted |
| quality | Talking video (standard, plus, max); face swap requires it | The render tier |
| Idempotency-Key | Header on the generate calls | That one call, not a retry, made the job |
| job id | Submit response; status and result URLs | The record you can read back later |
What the docs do and do not say
Avatar creation from a photo takes a public HTTPS image URL. Face swap takes a public HTTPS source video, and rejects signed or private URLs. Because both are public URLs, copy the file to storage you control and record its hash, since the URL may stop working. The avatar docs describe no age check, no signature check and no claim that the subject agreed. Do not infer protections the docs do not list.
Sume's docs describe resource routes for reading avatars and avatar videos, so you can list what exists under an account. Use them to reconcile your log against what was actually created.
An example record
A single row in your log could read: handle product_host, source URL stored in your own bucket with its hash, quality plus, key avatar-profile-001, job id from the submit response, and a link to the signed consent form. Five fields and one document answer most questions that come back months later.
If you run a campaign with many variants, add the variant label. For face swap, store the original source clip as well as the output, since the audio in the output is the source audio.
A short consent checklist
This is general practice, not legal advice or a Sume feature. Ask for consent that names the uses: face, voice, the kinds of video, the platforms and the end date. Store it with the handle. Tie deletion requests to the handle so you can find every video made from it. For face swap, remember that the source audio stays in the output, so the consent should cover the voice in the source clip as well as the face.
- One avatar handle per consenting person.
- Re-ask when the use changes, for example from internal training to paid ads.
- Keep job ids for as long as the videos are in use.
Sources
Related posts
More in Sume Avatar 1.0
- Which MCP grant lets an agent create an avatar? Write, no paid scope
On Sume's hosted MCP, avatars_create and the avatar video tools are paid tools that need the Write toggle at consent. There is no mcp:paid scope.
- Avatar video request rejected? Pre-flight these 6 inputs
Catch Sume Avatar 1.0 rejections before you submit: script vs video_inputs, the 4-60 second window, silence scenes, HTTPS media and caption style. A checklist.
- Avatar preview final render has no webhook_url: poll the job
The preview generate-video call takes only quality, so it has no webhook_url. Poll the job, or use the direct avatar endpoint for a webhook-driven render.
- Face swap or talking video: which Avatar endpoint fits?
Pick Sume Avatar face swap (Beta) or Avatar talking video by what you have: footage with audio, or a script. Inputs, limits and polling side by side.
Written by Sume