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.
- Moving Company Spokesperson Ad: A 20-Second Avatar for About $4.90
A 20-second plus-quality Avatar 1.0 spokesperson clip costs about $4.90 on Sume, at 98 cents per 4 seconds. English only, with captions at $0.20 extra.
- Introducing Sume Avatar 1.0
Sume Avatar 1.0 is a multi-agent orchestration system as a single avatar model.
- Avatar Face Swap API (Beta): apply an avatar face to a video
Avatar Face Swap 1.0 is a Beta Sume endpoint that applies a ready avatar's face to a short public source video. Required fields, limits, and polling.
Written by Sume