Wan27 Submit Generation

This is the only node in the pack that can cost you money, and the author has clearly been burned before, because it is wrapped in more safety interlocks than a commercial espresso machine. Four separate conditions have to be true before it sends anything.

The reason it exists at all: Wan 2.7 is hosted-only. No weights, no local sampler. When 2.7 went up, the loudest reaction in the community was a flat "no open source, no thanks" - and the thread was 67 upvotes of dunking rather than a firestorm, because the local crowd had stopped tracking the numbered series. So if you're here, you've made the deliberate call that you want this model enough to rent it. Fine. Then the job is not accidentally renting it twice.

What it does

It consumes the receipt from Wan27 Estimate Credits, re-verifies everything, and POSTs exactly one generation request with your request_id as the idempotency key. Then it stops. No polling, no retry loop, no "let's just try again." The README is blunt about the philosophy: one submission, one task ID, and the retry decision belongs to you.

The verification chain, in order:

• Approval. approved_after_review must be exactly True. Default is off, and a falsy value raises "First display and review the estimate, then explicitly approve this generation."
• Request ID format. request_id must match 16–128 characters of letters, digits, underscore or hyphen. The empty default fails immediately with an instruction to reuse the same ID when retrying.
• Receipt integrity. review_json must be version 1, contain an input object, and its inputDigest must match a fresh hash of that input. Edited a field in the receipt? "Invalid review receipt. Run Wan27 Estimate again."
• Budget. The reviewed cost is compared to maximum_credits and refused if it's higher.
• Fresh price. It re-quotes the service and refuses if the current price differs from what you reviewed, or now exceeds your ceiling.

Only then does it send. If the service accepts but doesn't return a task object, you get a very specific error telling you the request may have been accepted, to inspect your tasks, and to reuse the same ID rather than submitting with a new one - because a new ID means a new charge.

The inputs that matter

review_json is a multiline STRING, and you wire the Estimate node's review_json output into it. Don't retype it; retyping is how digest mismatches happen.

approved_after_review starts false and you flip it manually. The README is honest that the node cannot verify a human actually looked at the preview, so keep untrusted or automated data away from this switch - nothing should be able to flip it for you.

maximum_credits is the trap. The default is 0.0, which means every submission fails on budget until you put a real ceiling in. Beginners hit this and conclude the node is broken. Put in the number you're willing to lose on this generation - not a huge one, that defeats the point.

request_id is your idempotency key: 16 characters minimum, stable for a given generation. Generate one, keep it, and reuse it verbatim if a submission times out or errors ambiguously:

python -c "import uuid; print(uuid.uuid4().hex)"

Store it somewhere you can copy from when you retry. What you must not do is mint a new one "just to be safe" after a network error - that's how the same request gets submitted and charged twice.

Two outputs: task_id, a STRING to wire into Wan27 Get Task, and submission_json, the raw service response for when you need to see exactly what came back.

Install

Manager, search "Wan27". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/NotUsingGithub/ComfyUI-Wan27.git

Restart. No third-party dependencies, no weights to download - the whole pack is stdlib HTTP. Token goes in the environment of the ComfyUI process:

export WAN27_ACCESS_TOKEN="your-token-here"

Never in a node field, never in the workflow JSON. The README calls this out repeatedly, and it matters: a workflow with a token baked into it is a leaked token the first time you share a PNG with embedded workflow metadata.

Where it bites

The cache is your friend here. This node is an output node, so hitting Queue runs it - but ComfyUI caches by inputs. Re-queue the identical graph unchanged and it serves the cached result instead of re-submitting. Change anything (a new request_id does it) and it runs again. That's a sane default, and it means "generate another one" is a deliberate act: new ID, fresh review, new approval.

Reset approval after a run. The author says it in the README. Leaving the switch on turns the next queue press into an un-reviewed spend.

Timeouts are ambiguous, not failed. A SERVICE_UNAVAILABLE from the client explicitly warns that the generation may still have been accepted. Go look at your task history on the site; if it landed, fetch it. If it didn't, retry with the same ID.

Only the fixed origin, and redirects are rejected. If a proxy or TLS interceptor sits between you and wan2-7.io/api/v1/, you get REDIRECT_REJECTED rather than your bearer token being posted somewhere else. Requests are capped at 32 KiB, responses at 2 MiB, HTTP at 120 seconds.

Your account and task data land in ComfyUI history. Share the workflow and you've shared the receipt and the task IDs. Worth knowing before you post a screenshot.