Direct answer
The short version
Treat each generation as a durable job, not a single HTTP request. Create a local job record before submission, save the provider task ID immediately, poll at a bounded interval, map provider-specific states into a small internal state machine, and download successful output before its link expires. Never create a replacement task merely because a poll timed out; first reconcile the existing task so a transient network failure does not become a second paid generation.
Why do video APIs return a task instead of a file?
Video generation usually takes longer than a normal request-response cycle. Alibaba Cloud documents Wan video generation as an asynchronous flow that creates a task and then queries the result. MiniMax likewise separates video generation into task creation, status checks and file retrieval.
The first successful response therefore proves only that the provider accepted a task. It does not prove that generation completed, that the output passed review or that the result was stored permanently. Your workflow must preserve enough state to continue after a process restart or temporary network failure.
- Create a local job ID before calling the provider.
- Record provider, model, region, request time and a non-sensitive input fingerprint.
- Store the provider task ID as soon as it is returned.
- Keep generation content and credentials out of operational logs by default.
Which states should your job record support?
Provider state names differ. Alibaba's Wan reference includes PENDING, RUNNING, SUCCEEDED, FAILED, CANCELED and UNKNOWN. MiniMax documents Preparing, Queueing, Processing, Success and Fail. A connector should preserve the raw provider state while mapping it to a stable internal set.
A practical internal model is submitted, queued, running, succeeded, failed, canceled and unknown. Unknown is not the same as failed: Alibaba states that an expired or missing task can return UNKNOWN, so the operator may need reconciliation rather than an automatic resubmission.
- Save every state transition with a timestamp.
- Treat succeeded, failed and canceled as terminal unless current provider documentation says otherwise.
- Keep the provider request ID and sanitized error code for support and reconciliation.
- Show stalled and unknown jobs separately from confirmed failures.
How often should you poll, and when should you stop?
Use the provider's current guidance rather than a universal interval. Alibaba's Wan reference gives 15 seconds as a reasonable example and lists a default query limit of 20 requests per second. MiniMax's video guide uses a 10-second polling interval. These are provider examples, not guaranteed service levels.
Apply backoff and a maximum elapsed time in your own workflow. When the application reaches that limit, mark the job as needing reconciliation and continue to preserve the known task ID. A client timeout must not silently create a replacement paid task.
- Add small random jitter so many jobs do not poll at the same instant.
- Stop polling immediately on a documented terminal state.
- Respect account and query rate limits across all workers, not per browser tab.
- Use callbacks only after authenticating events and testing missed-event recovery.
How do you prevent duplicate paid generations?
The risky gap is between provider acceptance and local persistence. If the provider creates a task but the response is lost, an automatic retry may create a second charge. A local idempotency record and an explicit reconciliation state make that failure visible.
Not every provider documents a native idempotency key for every video endpoint. When one is not documented, your application should make resubmission a deliberate action after checking the existing task, account history and current provider guidance.
- Assign one local job ID to one approved generation attempt.
- Lock the job while submission is in progress.
- Store the provider task ID before allowing another attempt.
- Require an operator or explicit policy decision before replacing an uncertain task.
- Record the reason for every resubmission so costs can be reconciled.
What should happen when the result link expires?
Generated-file links are not necessarily permanent storage. Alibaba's Wan documentation says its task ID and returned video URL are valid for 24 hours. MiniMax returns a file ID that is then used through its file-retrieval flow. The exact retention rule must be checked for the selected model and region before production use.
Download a successful result promptly into storage controlled by the customer, verify the transfer, and record the storage reference without retaining a signed download URL in broad logs. A successful provider state should not become an operational success until the required file is safely available.
- Queue download work immediately after a successful terminal state.
- Verify file size and media readability before marking delivery complete.
- Keep signed URLs and authorization headers out of analytics and support tickets.
- Apply the customer's retention and access policy to the saved file.
Which failures can be retried safely?
Separate query failures from generation failures. A timeout or rate-limit response while checking status usually calls for a delayed status query, not a new generation. Alibaba and MiniMax both publish error references that distinguish authentication, quota, input, rate-limit and internal-service conditions.
Retry policy should follow the current documented error meaning. Authentication, invalid input, insufficient balance and content-policy failures need correction or review. Transient query and internal-service errors may justify bounded retry, but a new paid generation should never be the default recovery for an uncertain task.
- Retry status queries with backoff when the existing task ID is known.
- Do not retry invalid or disallowed input without a deliberate content change.
- Stop on credential, balance or permission errors and surface a clear operator action.
- Cap retry counts and preserve the last provider error code and request ID.
What should a production-readiness test include?
Run the workflow with synthetic, non-confidential media before using customer material. Test a normal success, a restart after submission, a temporary polling failure, a terminal provider failure and a delayed download. Confirm that none of these cases creates an unapproved duplicate generation.
IT CaoCao can review the state model, retry boundaries and handover checklist without receiving provider credentials or generation content. The customer continues to own and fund the third-party provider account.
- Every accepted task can be recovered by local job ID and provider task ID.
- Polling stays within the provider's current limits.
- Terminal failures are visible and do not loop indefinitely.
- Successful output is copied before the documented link or task window expires.
- Operators can reconcile cost, status and resubmission decisions without viewing content.
Frequently asked questions
Questions buyers ask next
Should a timeout create a new AI video generation task?
No. First retry the status query or reconcile the known task. A timeout can occur after the provider accepted the original request, so immediate resubmission can create a duplicate paid generation.
Can every Chinese AI video API use the same polling interval?
No. Provider guidance and account limits differ. Alibaba's Wan documentation gives 15 seconds as an example, while MiniMax's guide uses 10 seconds. Check the current endpoint documentation and apply bounded backoff.
Is a successful task status enough to keep the video?
Not necessarily. Result links can expire. Download and verify the file promptly, then store it according to the customer's own retention and access rules.
Primary sources
Evidence reviewed
Provider documentation changes. Recheck the live source before making a procurement decision.
- Alibaba Cloud Model Studio: Wan text-to-video API referenceAccessed 2026-08-17
- MiniMax API: video generation workflowAccessed 2026-08-17
- MiniMax API: video generation task statusAccessed 2026-08-17
- Alibaba Cloud Model Studio: error codesAccessed 2026-08-17
- MiniMax API: error codesAccessed 2026-08-17