Video generation API production checklist: prove recovery before launch

A video generation API production checklist should prove that your application can recover accepted work, explain failed work, and deliver successful work. One happy-path request demonstrates connectivity. It does not demonstrate that a lost response, duplicate message, or failed storage copy will behave safely after launch.

Use recorded responses and local fixtures for most of this review. Paid generation calls should be a deliberate, budgeted final validation step, not an accidental side effect of every deployment check. Read-only checks of known jobs can verify authentication and response handling without creating new renders.

Review each durable boundary

Area	Evidence required before launch
Acceptance	The returned job_id is saved before the customer sees accepted
Deduplication	Repeated local actions cannot silently dispatch twice
Observation	GET responses use id and all five states are handled
Recovery	A restarted worker resumes the saved remote identifier
Delivery	Successful outputs are validated and stored independently
Accounting	Held and actual credits remain attached to the request
Ownership	Backend tracking and assets enforce application authorization

The public job route checks the Genace account owner. Your application may still serve many customers through one account, so enforce the customer’s ownership of your local tracking record as well. Do not assume the gateway can identify your application-level customer from a shared key.

Inspect failure handling as a product flow

Test an HTTP error and a terminal failed job separately. The latter can arrive in an HTTP 200 response. Test outputs equal to null, progress equal to null, and a succeeded job with no usable artifact. The user should receive a precise status rather than a broken download link or an indefinite spinner.

Confirm that 402 responses stop automatic creation retries. Confirm that the two 429 error codes lead to different recovery decisions. Confirm that a lost generation response creates an ambiguous local attempt rather than immediately sending another POST.

Run a read-only smoke check

curl --fail-with-body \
  "https://genace.ai/api/v1/jobs/$GENACE_JOB_ID?wait=0" \
  -H "Authorization: Bearer $GENACE_API_KEY" \
  --output job-snapshot.json

Inspect the saved state, accounting fields, and output manifest without publishing private URLs. This command checks one known job; it is not a substitute for fixture-based recovery tests or a deliberate end-to-end generation review.

Confirm operational ownership

Assign someone to investigate old active jobs, ambiguous submissions, failed file copies, and credit mismatches. Ensure logs contain a local request identifier and remote job ID but omit raw API keys and sensitive signed URLs. Separate render latency from collection lag and delivery latency so an alert points to the correct subsystem.

If you offer cancellation, the UI should describe the implemented gateway cancellation behavior and use the returned terminal state. If you offer background collection, configure a durable scheduler; a timer in a terminated function is insufficient. Do not advertise customer webhooks or idempotency headers that your integration has not implemented.

Final verification checklist

Demonstrate a restart after acceptance, a duplicate queue delivery, a failed read, a terminal failure, and a failed artifact copy. Verify that each recovery reuses the correct identifier and that only a new authorized generation action can create additional paid work.

Use the detailed guides for observability, duplicate requests, and download validation.

Continue with production operations

• AI video API webhook vs polling: which one to use and when
• How to call a video generation API without blocking your agent
• generation operation unique key: deduplicate local intent without inventing API idempotency
• Browse all production operations guides