Wan 3.0 API Errors: Every Rejection, With the Exact Response

Every error below is the literal response body from the Wan 3.0 video endpoint, captured on 4 September 2026. No paraphrasing, no invented error text. If your request is failing, match the code field against this list.

model_not_found         → the model string does not exist
unsupported_parameter   → the value is out of range or not allowed
invalid_request         → a required field is missing
invalid_api_key         → the key is wrong, missing or revoked

The Errors, With Real Bodies

duration out of range

{"error":{"code":"unsupported_parameter","message":"duration 45 out of range [2, 30]"}}

Wan 3.0 accepts an integer from 2 to 30 seconds. Anything outside that fails, in both directions. Asking for 1 second returns the same shape:

{"error":{"code":"unsupported_parameter","message":"duration 1 out of range [2, 30]"}}

This is the single most likely error after an upgrade, for two different reasons:

• Coming from Wan 2.7 or 2.6, your code probably clamps to 15 seconds, which was their ceiling. That will not error, it will just quietly cap you at half the range Wan 3.0 offers. The Wan 3.0 vs Wan 2.7 comparison covers the rest of what moved.
• Coming from Seedance 2.5, your code probably enforces a 4-second minimum, because that is Seedance’s floor. On Wan 3.0 that leaves 2 and 3 second clips unreachable for no reason.

One rule that is easy to miss: when you pass input video for continuation, Alibaba’s API reference states the input duration plus the output duration together cannot exceed 30 seconds. The 30 is a total budget, not an output allowance on top of your input.

aspect_ratio not supported

{"error":{"code":"unsupported_parameter","message":"aspect_ratio \"21:9\" not supported; allowed: [16:9 4:3 1:1 3:4 9:16 adaptive]"}}

Wan 3.0 has no 21:9. The error helpfully prints the full allowed set, which is worth reading carefully because it differs from its neighbours in both directions:

So a pipeline that routes between Wan 3.0 and Seedance 2.5 cannot share a hardcoded 21:9. Either render 16:9 on Wan and crop, losing vertical resolution, or send cinematic jobs to Seedance. Going the other way, 4:3 and 3:4 work on Wan 3.0 but not on Wan 2.7, so a downgrade path breaks where the upgrade path does not.

resolution not supported

{"error":{"code":"unsupported_parameter","message":"resolution \"4k\" not supported; allowed: [480p 720p 1080p]"}}

480p, 720p and 1080p only. There is no 4K in this generation, and Seedance 2.5 also tops out at 1080p. If a 4K requirement is real, no parameter tweak on either model satisfies it. The one model in the catalog that does list 4K is the older bytedance/seedance-2.0 flagship at $0.07 per second, covered in the Seedance 2.0 vs Wan comparison.

Note that Wan 3.0 defaults to 1080p when you omit resolution, while Seedance 2.5 defaults to 720p. That difference does not throw an error, which is what makes it dangerous in a side-by-side test. Pin the resolution on both when comparing.

model_not_found

{"error":{"code":"model_not_found","message":"model not found"}}

The string does not exist in the catalog. Valid Wan 3.0 strings on Ofox:

• alibaba/wan-3.0
• alibaba/wan-3.0-prime
• wan-3.0-20260824 and wan-3.0-prime-20260824 as dated aliases

The trap is that Alibaba’s own model string is different. On Alibaba Cloud Model Studio the strings are wan3.0-video and wan3.0-video-prime, with no hyphen after wan and a -video suffix. Copying a model name straight out of Alibaba’s documentation into a gateway call produces exactly this error. Check GET /v1/models when in doubt; it is the authority on what is callable.

invalid_request

{"error":{"code":"invalid_request","message":"prompt is required"}}

A required field is missing. Distinct from unsupported_parameter, which means you sent a value that exists but is not allowed. The distinction matters when you write retry logic: neither is worth retrying unchanged, but the fix is different. A missing field is a bug in your request builder; an out-of-range value is usually a config or user-input validation gap.

invalid_api_key

{"error":{"code":"invalid_api_key","message":"invalid API key"}}

The key is wrong, missing, revoked or from the wrong account. Check that the Authorization header reads Bearer <key> and that the key is loaded from the environment rather than silently empty. An empty variable produces this error, not a missing-header error, which sends people looking in the wrong place.

What Is Not an Error

Video generation is asynchronous. A successful create returns a task, and you poll it or supply callback_url and get told when it finishes. A pending or in-progress status is not a failure, and alerting on it produces noise that buries the real failures. Only terminal failure states and the codes above deserve a page. The video API polling guide covers the wait behaviour and what a reasonable poll interval looks like.

A Request That Works

Once you have matched your error above, this is the shape that passes every check on this model:

curl -X POST https://api.ofox.io/v1/videos \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "alibaba/wan-3.0",
    "prompt": "A paper boat drifting down a rain gutter, close on the water line",
    "duration": 5,
    "resolution": "1080p",
    "aspect_ratio": "16:9"
  }'

Every field there is inside the accepted range: the model string exists, 5 is within [2, 30], 1080p is in the allowed resolution set and 16:9 is in the allowed aspect set. Change one of them to something outside those bounds and you get the matching error above, which is a quick way to confirm your error handling works before you need it.

For what the model costs once the request succeeds, and how the flat per-second rate compares to Alibaba’s resolution-tiered pricing, see the Wan 3.0 pricing and access guide.

Sources

• https://help.aliyun.com/zh/model-studio/wan3-video-generation-api-reference
• https://ofox.io/models/alibaba/wan-3.0

Every error body in this post was captured from live requests to the Ofox /v1/videos endpoint on 4 September 2026. Error text on other routes, including calling Alibaba Cloud directly, uses a different envelope and different codes.