Wan 3.0 request returns 409 idempotency_conflict after a prompt edit

A wan-3.0 request returns 409 idempotency_conflict when you reuse an Idempotency-Key with a different payload. The key means "this exact operation": the same key and the same body returns the original job without billing a second one, while a new prompt needs a new key. Fix it by minting a fresh key whenever any field changes.

Behavior comes from Sume's Generation admission docs and Jobs and results docs, read 2026-10-02.

Why does Sume return 409 and not run the new prompt?

Because the key already maps to a job. Sume refuses to guess whether you meant a retry or a new request, and a silent second run could bill twice. The docs list the code under immediate rejections: 409 idempotency_conflict means the key was reused for a different operation or payload.

How do I choose keys for a batch?

Build the key from the clip's identity, not from a timestamp: for example a campaign name, a shot number and a version, such as spring-shot-04-v2. A retry then reuses the key, and a re-render bumps the version. Keep the key with the job id in your own records.

A random key per attempt defeats the purpose, since a timed-out request cannot be matched to its retry.

What if I only changed the prompt slightly?

Any change counts. Even a one-word edit to the prompt, a changed duration or a different resolution makes it a different operation. Do not try to patch the old job; submit a new request with a new key, and cancel the old job if it is still queued.

For safe retries after a timeout, resend the identical body with the identical key. See idempotency keys for AI video APIs and cancelling a queued job.

A quick test for your own code: submit the same body twice with one key and confirm you get the same job id back; then change one word with the same key and confirm you get the 409. If both behave as described, your retry logic is safe.