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

Twenty-four hours on the task ID and twenty-four hours on the file

Wan 3.0 expires results after 24 hours. Not the file, and separately the record — both. The task ID stops resolving and the returned file URL stops serving, on the same clock.

That single line in the parameter table has more consequences for an integration than the resolution tiers do, and it is the line most often left out of tutorials, because a tutorial finishes inside one session and never notices.

What breaks, in the order it usually breaks

The gallery. The obvious one. If you store the vendor's URL in your database and render it in a "my creations" list, every row older than a day is a broken video element. You have to download the bytes and re-host them, and you have to do it inside the window.

The retry. Less obvious and more expensive. A job runner that picks a failed row off a queue and re-checks the task ID will, after 24 hours, get "not found" — which is not the same as "the job failed". If your error handling treats an unresolvable task ID as a failure and resubmits, you have just paid a second time for a clip that succeeded yesterday. The correct handling is to treat expiry as a terminal, non-retryable state, and that means you have to be able to tell it apart from a genuine failure, which means recording your own submission timestamp rather than relying on the vendor to still know.

The audit trail. If a customer disputes a charge six weeks later, the vendor's record of that task is gone. Whatever you want to be able to say about it — the prompt, the model ID, the returned duration and resolution, the reported cost — you have to have written down yourself, at the time. Nobody thinks about this until the first dispute.

The shape of the fix

Treat the vendor URL as a handle with a lease, never as storage:

  1. Poll to completion, then immediately fetch the bytes to your own object store. Not lazily, not on first view — immediately, in the same worker that saw the job complete.
  2. Persist your own row before you fetch: submission time, model ID, the exact prompt sent, and the usage block the response returned. That row is the audit trail; the video file is just a large attachment to it.
  3. Give expiry its own terminal state, distinct from failure, and make it unretryable.
  4. If the download itself fails, that is the only thing worth retrying, and it has a hard deadline — you get one day, not indefinite backoff.

The general version of this is older than generative video: any URL you did not issue is a lease, and a lease you have not read the term of is a bug you have not hit yet. What is unusual here is how short the term is. A day is short enough that a weekend deploy freeze can span it.

Checking it yourself

Alibaba documents the expiry in the create-task schema. Every published parameter for this model — the 2-to-30-second range, the 30 fps output, the three resolution tiers, the concurrency limit, and this expiry — is listed with its source and the date it was last verified on the Wan 3.0 specification table. Read 2026-09-07. Check the citations rather than take this page's word for it; being checkable is the point.

Disclosure: this site is written by the people who run a third-party browser interface to this model. We are not affiliated with Alibaba or Alibaba Cloud.