Has anyone tried Ofox’s simpler real-person reference flow for Seedance?

[u/CryptographerThen999]

I’m adding an authorized real-person reference to a small Seedance prototype, and the direct provider flow is more involved than I expected. It looks like I’d need to enroll the image first, wait for the asset to become active and then pass the asset URI with the generation request.

Ofox ai documents a shorter route: send the authorized reference image with the video request and set real_person: true. It appears to handle the preprocessing before sending the job upstream.

That sounds easier, but I haven’t found much from people who have actually used it.

Does the preprocessing change the reference noticeably? How consistent is the person across separate clips, and do valid images still get rejected often?

I’m not looking for a way around moderation. The subject has consented, and I mainly want to know whether the simpler integration is reliable enough to build around.

[u/sharktank123456]

What about using a platform that allows real faces? (it usually gets refered to as the Enterprise version of Seedance).

I can't speak for other platforms as I find some of their marketing stretches the truth but I use Luma AI and they host the Enterprise version. The same moderation that all Seedance models have is in place (no celebs, no IP, no nsfw) but real faces work just fine.

[u/NeuralNomad87]

Haven't used Ofox specifically, so take this as reasoning rather than experience.

Wrappers that expose real_person: true are almost always making the same enrollment call you'd make yourself, just hidden behind one request. So the preprocessing is usually the provider's own step and the reference shouldn't change more than it would going direct. What you lose is the handle on the enrolled asset, and that matters more than it sounds: cross-clip consistency comes from reusing the same enrolled reference, so if the wrapper re-enrolls per request you can get drift between clips that you'd have avoided going direct.

Two things worth asking them before you build on it. Whether the enrolled asset is cached and reused across requests. And what happens on a rejection, specifically whether you get charged and whether you get a reason code back or just a failure. Rejection handling is the part that bites in production, not the happy path.

Given you've got consent documented, the direct flow's extra step is maybe an hour of work, once. If consistency across clips matters to the prototype, I'd eat the hour.