Wan 3.0 Source NotesField notes on the Wan 3.0 video API — sourced, dated, and corrected in public.

Four model IDs became one, and your routing layer is now dead code

If you integrated Alibaba's video models before August 2026, you almost certainly wrote a router. Everyone did, because the API made you: text-to-video, image-to-video, reference-to-video and video editing were four different model IDs, each with its own capability envelope.

wan2.7-t2v         text to video, multi-shot, synced audio
wan2.7-i2v         first frame / first+last frame / continuation
wan2.7-r2v         reference to video, including audio reference
wan2.7-videoedit   instruction edits, video-to-video transfer

Wan 3.0 collapses all four into one endpoint:

wan3.0-video

There is no wan3.0-t2v. The mode is not something you select — it is inferred from what you put in input.media. Pass nothing, you get text-to-video. Pass a first_frame, you get image-to-video. Pass reference_image, you get reference-to-video. Same model ID, same parameter block, same response shape.

Everything below is from Alibaba Cloud's Model Studio documentation, checked 2026-08-27.

What that deletes from your codebase

The router. Any function shaped like pick_model(has_image, has_reference) has one possible return value now. Keep the function if it makes the diff smaller, but it is not doing anything.

The per-model capability table. This is the one worth actually deleting rather than neutralising, because a stale capability table is worse than no capability table. Under 2.7 the differences were real and you had to encode them:

	2.7	3.0
Duration, t2v / i2v	2–15 s	2–30 s, one rule
Duration, reference-to-video	2–15 s, or 2–10 s with a reference video	2–30 s, subject to input + output ≤ 30
Duration, video edit	2–10 s	2–30 s
Resolution	720P / 1080P on all four	480P / 720P / 1080P on the one
Frame rate	30 fps	30 fps

Three separate duration rules became one rule plus one arithmetic constraint. A table that still encodes "reference mode caps at 10 seconds" will refuse requests the API would accept.

The mode field in your own schema, if you have one. Users still think in modes — "I want to animate this photo" — so keep the concept in the UI. Just stop letting it reach the request builder, because the request builder's job is now to assemble media[], not to choose an endpoint.

The clearest way to see that separation is a front-end that kept all four doors open over a single endpoint: text to video, image to video, reference to video and video editing are four pages on the site I run, and every one of them posts the same wan3.0-video body with a different media array in it. The mode is a question about what the user brought with them, which is a UI concern. It stopped being an API concern in August.

What it adds

One validation responsibility that did not exist before, because the modes used to be kept apart by having separate endpoints.

first_frame and last_frame are the keyframe family. reference_image, reference_video, reference_audio, file and link are the reference family. Now that they share an array, it is possible to put both in — and the API rejects that:

{
  "code": "InvalidParameter",
  "message": "The two modes are mutually exclusive. Do not pass reference_xx and first_frame/last_frame at the same time."
}

Under 2.7 this was structurally impossible, because i2v and r2v were different URLs. Under 3.0 it is a validation rule you have to write yourself, and the cost of not writing it is that the user finds out after a submit round-trip instead of at upload time.

KEYFRAME  = {"first_frame", "last_frame"}
REFERENCE = {"reference_image", "reference_video", "reference_audio", "file", "link"}

def guard(media):
    kinds = {m["type"] for m in media}
    if kinds & KEYFRAME and kinds & REFERENCE:
        raise ValueError("pin the opening shot, or cast the subjects — not both")

Two capabilities that only exist on the merged endpoint

Worth knowing these are not in the 2.7 family at all, so they cannot be a migration — they are new surface:

• file — a document, up to 100 MB. Twelve accepted formats; the 50-page cap is validated for seven of them (pdf, docx, doc, pptx, ppt, key, pages), while xlsx, xls, txt, md and numbers are only size-checked.
• link — one public web page. Alibaba's own wording: "Only supports parsing publicly accessible web pages that do not require login."

Both need parameters.enable_thinking: true. Left at its default of false, the request still succeeds and is still billed — the model just does not read the document.

The one thing that did not get merged

wan2.7-videoedit is still in QwenCloud's model list. It was not retired when 3.0 shipped.

So if you have a video-editing path in production against 2.7, migrating it is a choice rather than a deadline. Worth checking your own traffic before doing the work: the 3.0 endpoint covers editing, but "covers" and "produces the same results on your material" are different claims, and only one of them is documented.

Migration order that minimises regret

1. Pin resolution explicitly everywhere, first. Under 2.7 the floor was 720P. Under 3.0 the default is 1080P — which is four times the 480P rate and twice 720P. A migration that changes nothing else still doubles your bill if the field is unset.
2. Replace the router with a single model ID.
3. Delete the per-model duration table; keep one rule and the input + output ≤ 30 check.
4. Add the two-family guard.
5. Only then look at the new inputs. Documents and links are the interesting part, and they are also the part where a mistake is silent.

---

Model tables from Alibaba Cloud's use-video-generation page and the wan3.0-video API reference; wan2.7-videoedit's continued availability from QwenCloud's video model list. Checked 2026-08-27.

I run wan-3.run, which is a hosted interface for the merged endpoint — the UI still shows four modes because that is how people think, but there is one request builder underneath. The first clip on it is free.