GPT Image 2.5 is live — OpenAI's newest image model, targeted edits that leave the rest of the frame alone
All Posts
Seedance 2.0 "Not Eligible": Why It Happens, What Works
2026/07/03

Seedance 2.0 "Not Eligible": Why It Happens, What Works

The Seedance 2.0 not eligible error is face and IP detection under ByteDance's own API rules: what triggers it, what to verify, and what works.

If Seedance 2.0 keeps stamping "Not eligible" on your reference image, you are not being throttled and you did not break a hidden rate limit. You are hitting a content check that ByteDance enforces at the model level, and its two documented triggers are real human faces and protected intellectual property[1]. Provider interfaces may surface that rule differently, which is why the error can feel unclear.

This post assembles what is actually written down: ByteDance's own eligibility rules and error codes, what platform interfaces are checking, what model and provider details to verify, and the routes that legitimately work when your project involves real people.

TL;DR

  • "Not eligible" is face and IP detection. Higgsfield's own interface explains the failed state as "This image contains faces or IP and cannot be used," and refunds the credits[2][3].
  • The rule comes from ByteDance, not the platform. The official API documentation states Seedance 2.0 models "do not support direct upload of reference images or videos containing real human faces"[1].
  • There is no moderation off-switch. The official Seedance 2.0 API exposes no safety parameter; input and output are both screened[1][4].
  • If behavior appears to change, verify the exact model. Dreamina applies the real-face restriction to Seedance 2.0 and 2.0 Fast, but not to the older Seedance 1.5 Pro[5]; published content policies can also vary by model[2].
  • Legitimate routes exist: ByteDance documents three exemption paths, including a consent-verified upload channel[6], and reAPI's face-enabled Seedance tier is built for exactly that workflow.
  • Do not try to defeat the check. The acceptable-use policy prohibits attempts to bypass safety filters[8], and the documented workflow includes output screening[6].

What "not eligible" actually means

Higgsfield is where most people meet this error, so start there. The platform runs every reference through a content check with three states, and the interface strings are unambiguous: "Checking content…", "Eligible", "Not eligible." When the check fails, the interface says why: "This image contains faces or IP and cannot be used," or on generations, "This generation may involve protected IP or likeness rights"[2]. The pipeline even has a dedicated IP-detection stage, and flagged requests are not charged; Higgsfield's docs confirm credits come back automatically[3].

So the error is not about image quality, format, or your account standing. It is a verdict on the content: the system believes your reference contains a real person's face or someone's protected property.

The rule underneath: no real faces, no protected IP

The primary source is ByteDance's own API documentation, which states it plainly: Seedance 2.0 series models "do not support direct upload of reference images or videos containing real human faces"[1]. The error-code catalog is just as direct. InputImageSensitiveContentDetected.PrivacyInformation means the input "may contain real person"; the .PolicyViolation variant flags material that "may be related to copyright restrictions"[4].

The consumer side matches. When CapCut rolled Seedance 2.0 out globally on Dreamina, its newsroom post said the launch was "restricting certain capabilities… including the ability to make videos from images or videos that contain real faces," alongside technology "designed to block the unauthorized generation of intellectual property" and invisible watermarking of outputs[5]. Dreamina's model picker labels Seedance 2.0 with a flat "Real human faces are not supported."

The why is not mysterious either: Seedance 2.0's launch collided with studio copyright disputes serious enough that ByteDance paused the global rollout for a month[7]. Deepfake liability plus IP litigation equals a hard filter at the model boundary.

Worth knowing: there is no toggle. The official API's parameter set contains no moderation switch of any kind; screening runs on inputs and outputs both, and the acceptable-use policy you sign prohibits depicting "a person (living or dead)'s voice or likeness without appropriate consent" and any attempt to bypass safety filters[8].

Why the same workflow can appear inconsistent

Two documented differences are worth checking before you retry the same asset.

Different models, different rules. On Dreamina, the "real faces not supported" label sits on Seedance 2.0 and 2.0 Fast, but not on the older Seedance 1.5 Pro[5]. If a workflow used to work, confirm which model and version it actually selected.

Published policies vary by model. Higgsfield's trust page notes that moderation "is applied at the model level" and that "content policies may vary depending on the model being used"[2]. Compare the exact model selection and the provider's published rules instead of assuming two similarly named modes are equivalent.

One more source of confusion worth clearing up: "visual restriction" is not defined in the ByteDance or CapCut documentation cited here. Use the documented face-and-IP restriction instead of treating that phrase as a separate technical error.

The routes that legitimately work

Start with the split that matters: is your subject a real person, or is the detector wrong about a synthetic one?

If your character is synthetic and still gets flagged, first verify the exact model and input mode. Dreamina documents the real-face restriction for Seedance 2.0 and 2.0 Fast but not for Seedance 1.5 Pro[5], while Higgsfield states that content policies vary by model[2]. Those published differences are a safer basis for routing the asset than repeated attempts to alter the check.

If your subject is a real person, the answer is consent infrastructure, not tricks. ByteDance's own docs describe three exemption channels: content the platform itself generated for your account within the last 30 days can be trusted as input; a library of preset virtual avatars; and a verified route where a real person's identity and authorization are confirmed, after which their material is referenced through a dedicated asset ID[6]. That last one is the official answer to "how do I make videos of myself."

On reAPI, the Seedance 2.0 face tier is built for real-person reference workflows where you hold the subject's consent and the necessary rights, priced above the standard tier, with the same per-second billing and the same one-line model switch. Failed generations refund automatically, so an unexpected rejection costs nothing but time.

What not to do: attempt to obscure a face or otherwise defeat the check. The acceptable-use terms prohibit bypassing safety filters[8], and the documented workflow screens outputs as well[6]. Build on the sanctioned routes and the error stops being part of your workflow.

FAQ

What does "not eligible" mean on Seedance 2.0?

The reference you uploaded failed a content check for real human faces or protected intellectual property. Higgsfield's interface states it directly: "This image contains faces or IP and cannot be used"[2]. ByteDance documents the underlying input rule in its own API documentation[1].

Why does Seedance 2.0 block my AI-generated character?

The published documentation does not explain individual classifier decisions. Confirm that the asset is synthetic, then check the exact model and provider policy: Dreamina documents different face restrictions for Seedance 2.0 and the older Seedance 1.5 Pro[5], and Higgsfield says content policies can vary by model[2].

What is "visual restriction" on Seedance 2.0?

An unofficial phrase with no definition in the ByteDance or CapCut documentation cited here. Use the documented restriction instead: no real faces or protected IP in reference material[1][5].

Can I turn off Seedance 2.0's content moderation?

No. The official API has no moderation parameter, screening applies to both inputs and outputs, and the acceptable-use policy forbids circumventing it[4][8].

Which platform has the fewest Seedance restrictions?

There is no reliable single answer across all models. ByteDance documents the Seedance 2.0 input restriction at the API level[1], while Higgsfield states that content policies can vary by model[2]. Compare the exact model and published provider rules; for real-person work, use the documented consent-based channel[6].

Do failed "not eligible" generations cost money?

Generally no. Higgsfield auto-refunds flagged requests[3], and on reAPI failed tasks refund automatically as well.

Why are celebrities blocked even in stylized images?

The published sources do not describe a separate celebrity-recognition mechanism. They do state that generations may involve protected IP or likeness rights[2] and that Seedance uses technology intended to block unauthorized IP generation[5].

How do I make Seedance 2.0 videos with my own face?

Through the verified-consent route: ByteDance's documentation describes identity verification plus authorization, after which your material is referenced via a dedicated asset channel[6]. reAPI's face-enabled tier supports real-person reference workflows for API users who hold the subject's consent.

Designing around the rules, not against them

The documented pattern behind the "not eligible" error is a model-level face-and-IP rule introduced amid copyright scrutiny. Fighting it wastes time and violates the terms; understanding it turns the error into a routing decision. Synthetic subjects call for checking the exact model and input mode, real people use the consent channels, and the face-enabled Seedance 2.0 tier on reAPI turns the sanctioned path into an API call.

References

  1. BytePlus (ByteDance). ModelArk — Seedance 2.0 input rules ("do not support direct upload of reference images or videos containing real human faces"). Retrieved July 2026 from docs.byteplus.com/en/docs/ModelArk/1520757
  2. Higgsfield. Trust & safety page and production interface strings ("Not eligible", "contains faces or IP"). Retrieved July 2026 from higgsfield.ai/trust
  3. Higgsfield. API documentation FAQ — flagged requests are not charged. Retrieved July 2026 from docs.higgsfield.ai/docs/help/faq
  4. BytePlus (ByteDance). ModelArk — content moderation error codes (PrivacyInformation, PolicyViolation). Retrieved July 2026 from docs.byteplus.com/en/docs/ModelArk/1299023
  5. CapCut Newsroom. Dreamina Seedance 2.0 global rollout — face and IP restrictions, invisible watermarking. Retrieved July 2026 from capcut.com/newsroom/dreamina-seedance-2
  6. BytePlus (ByteDance). ModelArk — trusted-input exemptions and consent-verified asset channel. Retrieved July 2026 from docs.byteplus.com/en/docs/ModelArk/2291680
  7. Reuters. ByteDance suspends launch of video AI model after copyright disputes. Retrieved July 2026 from reuters.com/technology/bytedance-suspends-launch-video-ai-model
  8. BytePlus. Generative AI Acceptable Use Policy. Retrieved July 2026 from docs.byteplus.com/en/docs/legal/acceptable_use_policy_byteplus_genai

Further reading

All Posts

More Posts