Put a real person in AI video, and keep it the same person in the next one
Generate a video twice from the same description and you get two different faces. Enrolling fixes that: the person does a one-minute liveness check on their own phone, you get an asset id back, and every clip you pass it to is the same face. There is a human step and it cannot be automated away — that is the first thing to know, and the rest of this page is what it costs you in practice.
The part that is not an API call
A real person has to be holding their phone. They scan a QR code, nod and blink for about a minute, and that is what proves the face being enrolled belongs to someone who agreed to it. No server-side call can stand in for that, by design — it is the consent, not a formality in front of it.
So this fits a flow where a person is present and cooperating: onboarding a spokesperson, a creator enrolling themselves, a customer who has agreed to appear. It does not fit a batch job over a folder of photographs, and it is not meant to.
The liveness session that init returns carries expires_in_seconds: 120. Two minutes from creating it to the person finishing. Generate it when they are already looking at their phone, not at the top of your form.
The whole flow, four steps
POST /api/v1/realface/init
Send a name. Returns a group_id, a link to show as a QR code, and the two-minute clock.
They scan it and do the liveness check. Nod, blink, about a minute. No government ID, no account to create, no name to verify.
GET /api/v1/realface/status?groupId=…
Returns pending_validation until they finish. Poll this rather than guessing.
POST /api/v1/realface/enroll
Send the photo URL and the group. Returns the asset id you pass as real_face_asset_id on every later video call. One payment, reusable afterwards.
Call step 4 before step 2 has finished and you get a 425 that says the group is not active, and it also says “No payment was taken.” Nothing is charged for getting the order wrong, which is worth knowing before you build the retry.
What we receive, and what we do not
Worth stating exactly, because the two halves are different and it would be easy to round them into one reassuring sentence.
The liveness capture. It goes from the person's phone to the identity service directly. The biometric data never reaches our servers and we have no copy of it.
The enrollment photo. You give us a URL, we fetch those bytes and forward them to be matched against the liveness result. That one is a normal request through our server, not a direct browser upload.
And no identity document is involved at any point. The check proves the person enrolling is the person in the photo — it does not establish who they are, we never ask, and there is no account behind it.
If there is no real person, do not use this
The liveness step exists to get a real human's consent. For an invented character there is nobody to consent, nothing to prove, and no reason to make someone hold a phone. Virtual Portrait enrols a generated face the same way and skips the whole step.
Use the enrolled asset on the Seedance 2.0 family: 2.0, 2.0 Fast and 2.0 Mini all take real_face_asset_id. 1.5 Pro and 2.5 do not — send it to either and the face will not be applied, so check the model before you wire it in. Full request shapes are in the API reference, and the studio runs the same four steps in a browser if you would rather see it work before writing the integration.
Enroll a face
The first two endpoints cost nothing, so you can build and test the whole flow up to the payment before spending anything. Enrollment is $0.011, charged once, and the asset is yours to reuse.
Real person AI video questions: consent, liveness, cost, reuse
- How do I get the same face in every AI video?
- Enroll it once. The person completes a short liveness check on their phone, you get back an asset id, and you pass that id on each later generation. Without it every render invents a new face, because nothing ties one generation to the next.
- Can I enroll someone's face from just a photo?
- No, and that is deliberate. A real person has to hold their own phone and complete a liveness check, which is what proves the face belongs to someone who agreed to it. There is no server-side call that substitutes for that step.
- Does the person need to upload ID or create an account?
- Neither. The check is liveness only — nod and blink, about a minute — and it proves the person enrolling is the person in the photo rather than establishing who they are. No government document, no login, no name to verify.
- Does BlockRun see the face or biometric data?
- No. The liveness capture goes from the phone to the identity service directly and never reaches our servers. The enrollment photo is separate and does pass through us: you send a URL, we fetch it and forward it to be matched. Worth keeping those two apart rather than rounding them together.
- How long is the liveness link valid?
- Two minutes from the moment you create it. Generate it when the person is already looking at their phone rather than at the start of a form, or it will expire while they read the instructions.
- What happens if I try to finish before the liveness check is done?
- The request is refused because the group is not active yet, and the response says in as many words that no payment was taken. Poll the free status endpoint until it reports otherwise instead of retrying the paid call.
- How much does enrolling a face cost?
- One payment per enrollment, settled in USDC, and the asset is reusable afterwards at no further charge. Creating the session and polling its status are both free, so you can build and test the whole flow before you spend anything.
- Real face vs Virtual Portrait — which should I use instead?
- Use Virtual Portrait instead. The liveness step exists to capture a real human's consent, so for an invented character there is nobody to consent and nothing to prove — it enrols a generated face the same way and skips the step entirely.
- Which video models accept an enrolled face?
- The Seedance 2.0 family, including Fast and Mini, each taking the asset id as a parameter on an otherwise normal generation request. Enrolling does not change how you call video, it adds one field.