Wan Video API: Parameters and Prompts Across Versions

Switching Wan versions can look like a one-line change. With each::labs, the outer API call stays the same: send a model slug and an input object to the prediction endpoint, then select a different model when you want to upgrade.

The short answer: each::labs keeps the outer prediction endpoint stable across Wan versions, but the model-specific input schema does not stay stable. Changing the model slug may be one line; migrating the request can still require field renames, type changes, different frame inputs, and prompt retesting.

The problem sits inside input.

Wan 2.5, 2.6, 2.7, and 3.0 do not share one stable request schema. Field names change. Types change. Image-to-video moves from a generic source image toward explicit frame controls. In Wan 2.7, some shot direction that used to live in a structured parameter moves into the prompt.

So there are two separate compatibility questions:

1. Can the same each::labs endpoint call the new Wan model? Yes.
2. Can you reuse the same input object and prompt unchanged? Do not assume so.

This guide covers the current Wan video models available through each::labs, with most of the detail on text-to-video and image-to-video. The goal is not to list every Wan feature. It is to show what actually changes in an integration: parameter names, value types, prompt structure, and the work required to move between versions.

Wan 2.5 vs 2.6 vs 2.7 vs 3.0: API parameter changes

The version number is only one part of the upgrade.

The model slug changes. The schema behind input can change with it.

The table below summarizes what the current each::labs model pages show. If a field does not appear in a current request example, it stays marked as absent rather than being borrowed from another version.

Concept	Wan 2.5	Wan 2.6	Wan 2.7	Wan 3.0
T2V model slug	wan-2-5-preview-text-to-video	wan-v2-6-text-to-video	alibaba-wan-2-7-text-to-video	alibaba-wan-3-0-text-to-video
I2V model slug	wan-2-5-preview-image-to-video	wan-v2-6-image-to-video	alibaba-wan-2-7-image-to-video	alibaba-wan-3-0-image-to-video
Aspect control in T2V example	aspect_ratio	aspect_ratio	ratio	ratio
Prompt expansion	enable_prompt_expansion	enable_prompt_expansion	prompt_extend	prompt_extend
Duration in current T2V example	string	string	number	string
Resolution example	lowercase p, e.g. 720p	lowercase p, e.g. 1080p	uppercase P, e.g. 1080P	uppercase P, e.g. 1080P
I2V source image/frame	image_url	image_url	first_frame	first_frame
I2V end frame	not shown	not shown	last_frame shown	first/last-frame capability documented; current example does not show the end-frame field
Negative prompt	shown	shown	shown in T2V	not shown in current T2V example
Structured multi-shot field in current T2V example	not shown	multi_shots	not shown	not shown
Explicit audio field in current T2V example	not shown	not shown	not shown	audio

Schemas and request examples checked September 3, 2026.

These are the parameter names exposed by each::labs. If you call Wan through another API, verify that provider's schema rather than assuming the wrapper fields are identical.

There are a few different kinds of breakage hiding in that table.

Change type	What it means for your integration
Rename	The same broad control appears under another field name
Type change	The concept survives, but the serialized value changes
Removed control	Logic may need to move to another field or into the prompt
New capability	The application can send a new kind of input
Behavioural change	The request still validates, but the model interprets the prompt differently

A rename is easy to patch. A behavioural change is not.

That distinction becomes important once you start treating model upgrades as production changes rather than catalog updates.

The endpoint stays stable. The model contract does not.

The current Create Model Prediction endpoint is:

POST https://api.eachlabs.ai/v1/prediction

It requires Bearer authentication and a JSON body containing model and input.

A Wan 2.7 request can look like this:

curl -X POST https://api.eachlabs.ai/v1/prediction \
  -H "Authorization: Bearer $EACHLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "alibaba-wan-2-7-text-to-video",
    "input": {
      "ratio": "16:9",
      "prompt": "A cyclist crosses a wet city intersection at night.",
      "duration": 7,
      "resolution": "1080P",
      "prompt_extend": true,
      "negative_prompt": "low resolution, blurry, distorted"
    }
  }'

A successful creation response includes a predictionID for the asynchronous job.

The boundary to keep in mind is simple:

model decides which model you call.

input has to match that model.

That is also why the older top-level version property should not be used as a Wan selector. The current each::labs OpenAPI reference marks it as deprecated and ignored.

You may still find this in generated examples on individual model pages:

{
  "version": "0.0.1"
}

For new integrations, follow the newer OpenAPI contract and select the Wan model with model.

- "model": "wan-2-5-preview-text-to-video"
+ "model": "alibaba-wan-2-7-text-to-video"

That edit really is one line.

The rest of the request may not be.

A Wan 2.5 payload that still sends aspect_ratio and enable_prompt_expansion does not automatically become a Wan 2.7 payload just because the slug changed.

This is the abstraction boundary I care about in multi-model APIs. A common API can remove transport differences and integration plumbing. It cannot make every model input mean the same thing.

aspect_ratio and ratio describe the same broad product concept. They are still different request fields. The same problem shows up with prompt expansion, frame inputs, duration serialization, and model-specific prompt behaviour.

If an abstraction pretends those differences disappeared, they usually reappear later as output problems.

Use request_schema as the input contract

The safest way to inspect a Wan model is not to copy a request from an old article. Query the model catalog and read the schema returned for the exact slug you plan to call.

The List Models API returns model objects that include:

• slug
• output_type
• request_schema

request_schema is the JSON Schema for that model's inputs.

That answers the questions your application actually needs to know:

• Which fields exist?
• Which are required?
• Is the value a string, number, boolean, array, or object?
• Which enum values are accepted?
• Did a newer model rename or remove something?

Model pages are still useful for examples and capability descriptions. Your integration should validate against the current schema.

Text-to-video parameters: what changed between Wan versions

Text-to-video has the simplest input conceptually: text goes in, video comes out.

The request surface is less stable than that description suggests.

aspect_ratio became ratio

The current Wan 2.5 T2V and Wan 2.6 T2V examples use aspect_ratio.

Wan 2.7 T2V and Wan 3.0 T2V use ratio.

Earlier:

{
  "aspect_ratio": "16:9"
}

Newer:

{
  "ratio": "16:9"
}

If your product supports several models, you probably do not want that naming difference leaking into every UI component and request builder. Keep an application-level value such as aspectRatio, then map it in the adapter for the selected model.

If you work directly with each model schema, use the field exposed by that slug.

Prompt expansion changed names too

Earlier each::labs Wan examples use:

{
  "enable_prompt_expansion": true
}

Wan 2.7 and Wan 3.0 use:

{
  "prompt_extend": true
}

The names clearly point at related functionality. That does not prove they have identical defaults or behaviour.

For Wan 2.7, the underlying model documentation describes prompt_extend as prompt rewriting before generation.

That means there are two things to test during migration:

1. whether the new field is mapped correctly;
2. whether the rewriting stage still behaves the way your prompt templates expect.

The first is a schema problem. The second is a model-behaviour problem.

duration is not safe to normalize by guesswork

Current each::labs examples serialize duration differently across Wan generations.

Wan 2.5:

{
  "duration": "5"
}

Wan 2.7:

{
  "duration": 7
}

Wan 3.0:

{
  "duration": "15"
}

These examples do not describe every allowed duration. They do show that you should not infer the target type from another Wan slug.

Read the schema.

A mismatch like this is especially easy to miss when an SDK or client library quietly converts strings and numbers for you.

Treat resolution as a schema value, not display text

The same caution applies to resolution.

Current examples include:

"resolution": "720p"

and:

"resolution": "1080P"

Do not assume the API normalizes casing.

Your product can still display friendly labels such as “720p” and “1080p.” Just map those labels to the enum the selected model expects.

Negative prompting is not equally visible across versions

Wan 2.5 and Wan 2.7 T2V examples expose negative_prompt.

When the field exists, it gives you a clean place for exclusions instead of forcing the main prompt into a long chain of “do not” instructions.

But the rule is model-specific. Do not add negative_prompt because another Wan version had it. If the target schema does not expose the field, leave it out.

Wan 2.7 moves multi-shot structure into the prompt

The each::labs Wan 2.6 T2V request exposes multi_shots.

Wan 2.7 handles the underlying shot structure differently. Its current native documentation says shot_type no longer controls single- versus multi-shot generation; shot structure belongs in the prompt.

A multi-shot instruction can therefore be written like this:

Shot 1 [0–3s]: Wide shot of an empty train platform before sunrise. Static camera.

Shot 2 [3–6s]: A train enters from the left as the camera begins a slow lateral track.

Shot 3 [6–10s]: Medium shot through the carriage window as the train comes to a stop.

This matters more than a renamed JSON key.

Once control moves from a parameter into prose, the migration can affect:

• prompt templates,
• prompt validation,
• UI fields,
• presets,
• tests,
• stored user configurations.

The API can continue returning successful jobs while the product above it quietly stops expressing the same instructions.

Wan 3.0 exposes an explicit audio control

The current Wan 3.0 T2V example adds:

{
  "audio": true
}

That is a new input in the each::labs request surface rather than a renamed field.

Whether you use it is a product decision. Once audio is part of the generation, the rest of the application may also need to change: prompt fields for dialogue or ambience, media validation, playback, export handling.

A new field may be optional at the API layer and still create work elsewhere.

How to prompt Wan text-to-video

A good Wan prompt describes the shot. It does not repeat every structured setting already present in the request.

A useful structure is:

subject + action + scene + camera + visual treatment + timing or audio where relevant

For example:

A courier on a red bicycle turns into a narrow rain-soaked street at night. Neon shop signs reflect across the pavement. The camera tracks beside the bicycle at wheel height, then eases into a wider rear three-quarter view as the rider accelerates. Natural motion blur, realistic street lighting, restrained contrast.

That gives the model:

• subject: a courier on a red bicycle
• action: turning and accelerating
• environment: a wet urban street at night
• camera: tracking, height, framing transition
• look: realistic light, motion blur, restrained contrast

It does not also need “16:9, 1080P, seven seconds” if ratio, resolution, and duration already carry those requirements.

Keep structured controls structured when the API gives you that option.

Describe camera behaviour as an action

“Cinematic camera” says very little.

“Camera tracks beside the bicycle at wheel height” tells the model what to do.

Useful motion language includes a slow pan, a dolly in, an orbit, a locked-off frame, or a handheld follow. Use the movement that matters. A prompt does not become better because it contains more camera vocabulary.

For Wan 2.7 multi-shot video, write the timeline

This:

A woman enters a café, sits down, the camera changes, coffee arrives, then we see the street outside.

asks the model to infer several transitions at once.

A short timeline makes the structure explicit:

Shot 1 [0–3s]: Exterior wide shot of a small café on a rainy corner. Slow push toward the entrance.

Shot 2 [3–7s]: Interior medium shot as a woman in a dark coat sits by the window and places her bag beside the chair.

Shot 3 [7–10s]: Close-up of a coffee cup being placed on the table, with traffic moving softly out of focus through the window.

The second prompt is not better because it is longer. It separates actions, timing, and framing.

That also makes failures easier to diagnose. If the second shot is consistently wrong, you know where to start.

Prompt expansion changes the instruction path

Prompt expansion adds another stage between the text your application sends and the generation itself.

On Wan 2.7, prompt_extend is explicitly documented as prompt rewriting.

Treat it as a configuration to test, not as a “better prompt” switch.

A short intent such as:

A sailboat crossing a calm bay at sunrise.

leaves room for rewriting to add scene detail.

A carefully timed multi-shot prompt is different. If the application depends on exact camera or sequence instructions, test prompt expansion both on and off.

You need to know which instructions survive the rewrite.

Prompts are starting points, not portable contracts

I do not treat prompt enhancement as generic cleanup.

The target model matters. A prompt tuned for one model can get worse when it is “improved” into a longer, more generic version for another. Models differ in literalness, camera-language interpretation, and how much context they reward.

My rule is:

Prompt enhancement has to understand the target model, not just make every prompt longer.

That applies between Wan versions too.

Reuse an old prompt as a baseline. Do not assume it is the finished prompt for the new model. Run representative inputs through both versions, look at what actually changed, then retune where the evidence points.

Wan image-to-video parameters and prompt structure

For Wan image-to-video, prompt the motion rather than redescribing the source image. Specify what moves, how the camera behaves, what must remain consistent, and—when a last frame is supplied—how the scene should travel between the two states.

The source frame already establishes much of what a text-to-video prompt would otherwise need to describe:

• subject appearance,
• clothing,
• product shape,
• environment,
• color,
• composition,
• starting camera position.

So the prompt can focus on what changes.

image_url became first_frame

The current Wan 2.5 I2V and Wan 2.6 I2V examples pass the source image as:

{
  "image_url": "https://example.com/input.jpg"
}

The current Wan 2.7 I2V and Wan 3.0 I2V examples use:

{
  "first_frame": "https://example.com/input.jpg"
}

That change reaches beyond a request key if your application:

• uploads the asset,
• validates required inputs,
• stores reusable presets,
• exposes model parameters directly in a UI or SDK.

The name is different because the newer interface treats the supplied image explicitly as the first state of the video.

Last-frame control changes what the prompt has to solve

Wan 2.7's current each::labs I2V example exposes last_frame.

Wan 3.0's current page also describes first-and-last-frame generation as a capability, although its displayed example currently shows only first_frame.

With only a first frame, the prompt mostly answers:

What happens next?

With both endpoints defined, the problem changes:

How does the scene get from this state to that one?

Suppose the first frame shows a closed perfume bottle and the final frame shows the bottle open with its cap on the table.

A useful transition prompt is:

The cap lifts smoothly from the bottle and moves to the right before settling onto the table. The camera makes a very slow push-in throughout the shot. Keep the bottle centered and preserve its shape, label, reflections, and table position. Motion should be controlled and physically plausible.

There is no need to redescribe details the frames already establish.

Prompt motion, camera behaviour, and constraints

A useful I2V structure is:

motion + camera + consistency constraints + progression + audio where supported

For a portrait:

The subject takes a slow breath and turns her head slightly toward the window. A few loose strands of hair move in the breeze. Keep facial identity, clothing, background, and lighting consistent. Locked camera with only a subtle natural handheld drift.

For a product:

The sneaker remains fixed on the platform while the camera makes a slow clockwise orbit from front three-quarter view to side profile. Preserve the shoe shape, logo placement, sole geometry, and material texture. Soft studio reflections move naturally across the surface.

Notice what is missing: a complete inventory of what the image looks like.

The frame already carries that information.

Put structured controls in structured fields

If the model exposes a dedicated field for something, use it.

For example:

• frame input → first_frame
• output ratio → ratio where supported
• duration → duration
• resolution → resolution
• prompt expansion → the version-specific expansion field

This keeps the prompt focused and makes migrations easier to diagnose.

When a field disappears, you know which part of the application lost a structured control.

How to check the current Wan schema before you ship

Any article about fast-moving model APIs will age. Your integration does not have to age with it.

The List Models endpoint lets you inspect the current model catalog programmatically:

curl "https://api.eachlabs.ai/v1/models?name=wan&limit=50"

The endpoint does not require authentication.

It returns an array of model objects that include the slug and request_schema.

Instead of hard-coding an assumption like:

const wanDurationIsAlwaysANumber = true;

inspect the schema for the model you are about to call:

const response = await fetch(
  "https://api.eachlabs.ai/v1/models?name=wan&limit=50"
);

if (!response.ok) {
  throw new Error(`Failed to list models: ${response.status}`);
}

const models = await response.json();

const model = models.find(
  (item) => item.slug === "alibaba-wan-2-7-text-to-video"
);

if (!model) {
  throw new Error("Wan model not found");
}

console.log(model.request_schema);

At minimum, compare:

• required
• field names under properties
• types
• accepted enum values
• defaults where present

A schema check is useful as part of an internal model-upgrade process because it catches mechanical changes early:

aspect_ratio -> ratio
enable_prompt_expansion -> prompt_extend
image_url -> first_frame

What it cannot tell you is whether the new model still produces acceptable video.

That part requires output testing.

FAQ

Can I switch Wan versions by changing only the model slug?

You can select another Wan model by changing the model slug while keeping the same each::labs prediction endpoint. That does not guarantee that the old input object is valid for the new model.

Fetch the target model's request_schema, compare field names and types, then retest the prompts before you switch production traffic.

Does Wan use aspect_ratio or ratio?

Both names appear across current Wan versions on each::labs.

Wan 2.5 and 2.6 T2V examples use aspect_ratio. Wan 2.7 and 3.0 use ratio.

Use the field exposed by the exact model slug you are calling.

Can I reuse a Wan 2.5 prompt with Wan 2.7 or Wan 3.0?

Reuse it as a baseline, not as a contract.

Wan versions can differ in prompt interpretation and in how control is divided between structured parameters and natural language. Wan 2.7's multi-shot behaviour is one concrete example.

Run representative prompts through both versions. Retune based on the output your product actually needs.

What is prompt_extend?

prompt_extend is the prompt-rewriting control shown by current Wan 2.7 and Wan 3.0 examples on each::labs.

Earlier each::labs Wan versions expose enable_prompt_expansion.

Do not assume expansion automatically improves a prompt. Test the setting as part of the target model configuration.

Is version: "0.0.1" how I choose a Wan version?

No.

The current each::labs OpenAPI reference marks the top-level version field as deprecated and ignored.

Choose the model with the model slug:

{
  "model": "alibaba-wan-2-7-text-to-video"
}

Some current model-page examples still include "version": "0.0.1", but that field is not what selects Wan 2.5, 2.7, or 3.0.

How do I find the latest Wan API parameters?

Use the List Models API and inspect request_schema for the exact Wan slug you plan to call.

That is safer than assuming a code sample written for another Wan version still represents the current input contract.

Migrating between Wan versions

A safe Wan migration has two tests.

Mechanical compatibility: does the request validate?

Output compatibility: does the new model still produce video your product can use?

Passing the first test says very little about the second.

I treat model changes as production dependency changes for exactly this reason. An improvement on the provider's side can still be a regression on yours. The API can keep returning successful jobs while motion, identity consistency, framing, timing, or prompt interpretation shifts enough to change the product.

Version migration needs behavioural testing, not just a 200.

First classify the change

Before editing code, put each schema difference into a bucket.

Change	Example	Required response
Rename	aspect_ratio → ratio	Map the field
Type change	duration string → number in the target schema	Update serialization and validation
Removed control	structured shot control disappears	Move logic elsewhere
New capability	audio becomes available	Decide whether the product should expose it
Behavioural change	same prompt interpreted differently	Retest and retune prompts

This keeps you from treating every migration problem as JSON.

Wan 2.5 → Wan 2.6

The current Wan 2.5 and 2.6 each::labs examples preserve much of the same parameter vocabulary.

Both T2V surfaces include:

prompt
aspect_ratio
resolution
duration
negative_prompt
enable_prompt_expansion

Wan 2.6's current request adds fields including:

multi_shots
enable_safety_checker

That makes 2.5 → 2.6 look more like an extension of the earlier request surface than the naming break that comes with 2.7.

Still, compare the target schema before sending production traffic. Shared field names do not prove identical required fields, types, or enums.

Wan 2.6 → Wan 2.7

This is where the each::labs T2V request changes more visibly.

The proven field-name changes are:

 {
   "prompt": "A cyclist crosses a wet city intersection at night.",
-  "aspect_ratio": "16:9",
-  "enable_prompt_expansion": true
+  "ratio": "16:9",
+  "prompt_extend": true
 }

There are separate serialization differences too.

The current 2.6 example uses string duration and lowercase resolution:

{
  "duration": "15",
  "resolution": "1080p"
}

The current 2.7 example uses numeric duration and uppercase resolution:

{
  "duration": 7,
  "resolution": "1080P"
}

Those examples prove the request surfaces differ. They do not mean "15" maps to 7, or that one resolution value should be copied mechanically into another model.

Use the target schema.

There is also a prompt migration.

If a 2.6 application relied on structured multi-shot controls, renaming JSON fields is not enough. Wan 2.7's underlying model no longer uses shot_type to control single- versus multi-shot generation; the shot structure belongs in the prompt.

For I2V, another request change appears:

 {
   "prompt": "Slow camera orbit around the product.",
-  "image_url": "https://example.com/product.jpg",
-  "enable_prompt_expansion": true
+  "first_frame": "https://example.com/product.jpg",
+  "prompt_extend": true
 }

Adding Wan 2.7's last_frame control changes more than serialization. Your UI and prompt logic may now need to represent an intended end state.

Wan 2.7 → Wan 3.0

The current each::labs T2V examples have more naming continuity between 2.7 and 3.0.

Both expose:

ratio
prompt
resolution
prompt_extend

Wan 3.0's current example also adds:

{
  "audio": true
}

The current examples still serialize duration differently: Wan 2.7 shows a number, Wan 3.0 a string.

That is enough reason not to assume request compatibility because two payloads look similar.

For I2V, Wan 3.0 keeps first_frame rather than returning to image_url. Its current page describes first-and-last-frame generation as a capability, but the displayed request example does not expose the end-frame parameter. Check the current schema before wiring that capability into application code.

Before upgrading:

1. compare the exact 2.7 and 3.0 request_schema;
2. update fields that were renamed, added, removed, or retyped;
3. run the old prompts unchanged as a baseline;
4. inspect motion, camera compliance, identity or subject consistency, timing, and your product's own acceptance criteria;
5. retune only where the new model actually behaves differently.

There is no benefit in rewriting every prompt before you know what changed.

A safe Wan version-switch checklist

Before routing production traffic to another Wan version:

1. Identify the exact target slug.
   Do not migrate to a family name when the API expects a specific model.
2. Fetch its current request_schema.
   Treat that as the input contract.
3. Diff the field names.
   Look for changes such as aspect_ratio → ratio.
4. Diff field types and accepted values.
   Pay particular attention to duration, resolution, booleans, arrays, and required inputs.
5. Check I2V asset fields separately.
   image_url, first_frame, and last_frame affect application logic differently.
6. Find controls that moved into the prompt.
   A request can validate while an old prompt template no longer expresses enough information.
7. Run representative production inputs through both versions.
   Use the prompts, source images, shot lengths, and motion patterns your users actually send.
8. Compare output behaviour, not only API success.
   A successful prediction proves the job was accepted. It does not prove the new version behaves like the old one.
9. Then change the production model slug.

The outer each::labs call keeps the final switch small. It does not make the models interchangeable.

A unified API should remove the differences that are safe to abstract. Version-specific schemas and output behaviour are the parts worth keeping visible.

Canberk Sinangil

Co-founder & CTO

I’m the Co-Founder and CTO of each::labs, where I focus on building the infrastructure and tooling that help developers bring AI models into production. My background spans computer vision, augmented reality, machine learning, and software engineering, including building AR and visual AI products before moving deeper into generative AI. I’m particularly interested in the engineering challenges behind making powerful AI models fast, scalable, and practical for real-world products.

LinkedIn · X

Build your Workflow on each::labs

Run Wan versions through one API, inspect current model schemas, and move between models without rebuilding the surrounding integration.

Build your Workflow on each::labs