Choose API funding before building a video request

SeedanceCheap.com — from our team, with Codex. We operate the AI-video service discussed here and have a commercial interest in it. This is a practical account of a change to our free, local API request builder.

A free request-planning tool can still prepare a request that requires paid funding. Its interface should make that boundary clear before someone copies JSON into a terminal.

Our public cookbook previously put free_trial: true into every prepared pilot. That was a safe choice against accidental paid fallback, but it left developers with an awkward path when introductory trials were paused: the only prepared example selected a trial, even if the reader intended to use existing credits.

We changed the builder to require an explicit funding choice. It starts with neither route selected. The JSON preview stays empty and its download button stays disabled until the reader chooses trial or paid funding. The page still collects no API key and sends no generation request.

Capacity and funding answer different questions

A model accepting new requests does not establish that a trial is available to an account. Funding policy, account eligibility, current formats and model capacity can change independently.

For our API, an explicit trial uses free_trial: true. Trials must be enabled and the account eligible. A rejected trial does not silently fall back to a paid request. An explicit paid request uses free_trial: false and can use the account's credits or balance when the developer runs the submit command separately.

These flags describe the funding route. They do not promise admission, a completion time or a usable creative result. Check the current service terms and the model's live availability before submitting a request or buying credits.

Require a real choice in the local builder

The core rule is small. Here is a reduced example of the funding decision, rather than a complete API client:

function withFunding(savedInput, funding) {
  if (!['trial', 'paid'].includes(funding)) {
    throw new Error('Choose trial or paid funding first.');
  }
  return {
    ...savedInput,
    free_trial: funding === 'trial',
    auto_retry: false
  };
}

Our actual builder also validates the model, request ID and prompt. It fixes the corresponding duration, preserves the exact prompt text and updates the model-specific availability link. Its trial and paid selections produce different explicit JSON flags; the initial empty selection produces no executable example.

We retain auto_retry: false for this pilot. Automatic service retries have separate behavior and should be reviewed before the original submission. Changing a local preview does not change an already-submitted job.

Keep funding attached to the original request

Save a unique request ID and the exact JSON before sending. If the create response is lost, recover that same request through the documented lookup route. Keep its original model, prompt, funding choice and retry setting together.

A rejected trial is a reason to read the response and check policy or eligibility. Changing its flag to paid and resubmitting the same ID is not a recovery procedure. A deliberate new paid attempt needs its own saved request and ID after the original state is understood. Active or uncertain work needs reconciliation before another submission.

Also check HTTP outcomes explicitly in a client. Fetch can return a response for an HTTP error status; response.ok helps distinguish that response from success. See MDN's Fetch guide. Saving an error body gives you a receipt to inspect, rather than evidence that a video job exists.

What we checked

All 16 cookbook checks passed, including five API request and browser-history checks. The request checks cover both model durations and both explicit funding routes, rejection of missing or malformed funding, preservation of the prompt and request ID, recovery commands, and restoration of the selected fields after browser Back navigation. The browser fixture observed zero fetch calls from the builder.

In the native browser, we checked the initially blocked download, the trial and paid JSON previews, the model-specific link, Windows command syntax and an actual local JSON download. The exported JSON matched the preview. We inspected the funding control at a 320-pixel phone width and verified the exact public Pages build after publishing.

These are interface, local-export and regression checks. We did not run a generation or purchase for this guide. The checks do not establish customer delivery, creative usefulness or sales growth.

You can use the free request builder or inspect the published change. For the current service contract and model admission check, open the live SeedanceCheap API documentation.

Prepared by the SeedanceCheap team with AI assistance from Codex, using our implementation and saved verification results. The publisher is an independent service; this guide is free and generation has separate funding terms.

Try the eight-second portrait exercise

For a first test, watch the two animated wheel stops and decide what the finished shot needs to show. Then copy the timed stunt prompt and choose Portrait in the free request builder. Open the animation and copyable prompt.

On November 9, 2026, the exact eight-second Veo 3.1 text recipe listed 720 × 1280 portrait and a paid charge of 0.25 credit. That allocates about $0.25 from the $99 upfront 100-credit pack or about $0.63 from a single $2.50 credit purchase. Both are one-time credit purchases. The animation and builder are free. Check the current format and availability in the builder before buying or running the prompt.