Seedance 2.5 Content Filtering: Diagnosing a Refusal

Why did a Seedance 2.5 request fail: did the API reject the payload before a task existed, or did an asynchronous task later fail a safety check? The response already contains the evidence needed to separate those cases.

This guide uses the exact route, request fields, task status, error code, and settled usage to diagnose a refusal. It does not infer one host's behavior from another host or treat a less restrictive route as an unfiltered model.

TL;DR

Start with task creation, not elapsed time. A synchronous 400 means the request failed validation before a task was created. A task that later ends in failed must be diagnosed from its error and usage fields.^[2]^[3]
content_filter: false is not “unfiltered.” On reAPI it selects the Flexible channel, keeps the same pricing, and does not disable upstream policy checks.^[2]
Error 80006 does not name the moderation stage. It may refer to the prompt, a reference image or video, or the generated output.^[3]
Check the terminal bill. A failed task's usage.credits shows whether the reservation was fully refunded or a post-generation charge was retained.^[3]^[4]
Model facts worth knowing: Seedance 2.5 generates up to 30 seconds in one pass and accepts up to 30 images, 10 video clips and 10 audio clips as reference.^[1]

Why route details matter

Different access surfaces can validate and route the same model differently. On reAPI, content_filter is explicitly a routing control rather than an upstream model parameter. The default is true; direct API callers can set it to false to use the less restrictive Flexible channel, but moderation still applies.^[2]

Four observable stages matter during diagnosis:

Synchronous request validation. Bad fields or unsupported media return an HTTP error before a task is created.
Route selection. Supported requests are sent through the channel chosen by model-specific parameters such as content_filter.
Asynchronous task execution. The task moves through processing before reaching completed or failed.
Safety failure. Error 80006 can represent a rejected prompt, reference, or generated output; the generic code alone does not identify which safety check fired.^[3]

These are observable API stages, not a claim that every host implements the same internal pipeline.

Five checks that locate the failure

These checks use fields the API exposes. They do not require a deliberately disallowed prompt.

Check 1: did submission create a task?

Save the HTTP status and response body from the POST. A synchronous 400 with a 2xxxx error is request validation: fix the named field or media format. If the response contains a task ID, submission passed and later diagnosis belongs to the task record.^[2]^[3]

Elapsed time is supporting context, not proof of which internal component made the decision.

Check 2: record the route and routing fields

Save the endpoint, exact model ID, complete payload, and content_filter value. On reAPI, omitting content_filter means true; false selects the Flexible channel. Comparing results without recording that field compares two different routes.^[2]

Check 3: validate the reference contract

Use only reference material you own or have permission to process. Confirm that every URL is public HTTP(S), its actual file format is supported, and the image, video, and audio counts stay within the documented limits. Unsupported media returns a synchronous 400, so it should not be described as a model moderation refusal.^[2]

Check 4: inspect the terminal task error

Poll GET /api/v1/tasks/{id} until completed or failed. For a failed task, record error.code, error.message, the task ID, and the original request. Code 80006 confirms a content-policy failure but does not reveal whether the prompt, a reference, or the generated result triggered it.^[3]^[4]

Check 5: inspect settled usage

Read usage.credits from the same terminal task. Zero means the reservation was refunded; a positive value means a documented post-generation charge was retained. Do not infer the bill from the error message alone.^[3]^[4]

Why error 80006 does not identify the trigger

The public error contract deliberately groups several safety outcomes under one workflow code. A prompt, reference image, reference video, or generated output may trigger 80006.^[3] The code does not prove that a host rewrote the prompt, ran a particular face classifier, or changed a threshold.

Do not retry the same payload unchanged. First revise sensitive prompt text and verify every reference. If the model supports it and you are calling the API directly, content_filter: false can test the less restrictive route; it still does not switch safety review off.^[2]^[3]

Route and parameter facts you can verify

The route is asynchronous. Submit to POST /api/v1/videos/generations, retain the returned task ID, and poll GET /api/v1/tasks/{id}. Polling does not consume credits.^[2]^[4]

content_filter is model-specific routing. It defaults to true on the reAPI Seedance 2.5 route. Setting it to false changes the channel, not the price, and failures on that route remain possible.^[2]

The current reAPI resolution enum is 480p, 720p, or 1080p. Check the returned file before relying on a reseller's broader resolution label.^[2]

Reference limits are explicit. The model accepts up to 30 images, 10 video clips, and 10 audio clips; ByteDance describes the same multimodal reference capacity in its launch material.^[1]^[2]

FAQ

Is Seedance 2.5 uncensored?

No. On reAPI, content_filter: false means a less restrictive routing channel; the documentation explicitly says it does not turn moderation off and upstream policy checks can still fail the task.^[2]^[3]

Why did the same prompt work on one site and fail on another?

The outcomes are not comparable until you confirm the endpoint, exact model ID, payload, references, and routing settings. Record those values and compare the returned HTTP status, task error, and settled usage instead of guessing at an internal filter.

Why was my AI-generated character rejected as a real person?

The generic 80006 code cannot answer that. It says only that the prompt, reference material, or generated output triggered a safety check. Review all three inputs to the decision before changing the prompt.^[3]

Why did a prompt that worked last week start failing?

Reproduce it with the saved model ID, route, payload, and references. Then compare the new HTTP response and task error with the earlier record. Without those fields, a changed result does not identify what changed.

What resolutions does Seedance 2.5 support?

The current reAPI route accepts 480p, 720p, and 1080p. Verify the returned file before building a delivery contract around any resolution label.^[2]

How long can a single Seedance 2.5 clip be?

Up to 30 seconds in one pass.^[1]

Can I use a real person's face as a reference?

The reAPI request contract permits real-person reference material and reviews it automatically, but an accepted upload does not supply consent or likeness rights. Use only material you are authorized to process.^[2]

Reading a refusal instead of guessing at it

A refusal is a data point about one payload on one route. Save the POST response, task ID, exact model and routing fields, terminal error, and usage.credits. Those records separate validation from asynchronous failure and show the final charge without making unsupported claims about an internal moderation layer.

References

ByteDance Seed. One-take Creation, Flexible Referencing: Introducing Seedance 2.5. Published 31 July 2026, retrieved August 2026 from seed.bytedance.com/en/blog/one-take-creation-flexible-referencing-introducing-seedance-2-5
reAPI. Seedance 2.5 API — route, request parameters, reference limits, content_filter, task flow, and refund behavior. Retrieved August 2026 from reapi.ai/docs/seedance-2-5
reAPI. API errors — validation codes and 80006 content-policy handling. Retrieved August 2026 from reapi.ai/docs/api/errors
reAPI. Tasks API — status, settled usage, polling, and output contract. Retrieved August 2026 from reapi.ai/docs/api/tasks