Video generation API output storage: turn remote results into durable assets
Video generation API output storage begins after rendering succeeds. Genace job outputs contain a URL, a type, and a metadata object. That response tells your application where it can collect a result; it does not establish that the file has been copied into your storage or that the upstream URL has a documented permanent retention period.
Treat the source URL as a collection location. Save a manifest, copy the bytes, validate the file, and publish an application-owned asset reference. This makes delivery recovery independent from the original paid generation request.
Use two records with separate lifecycles
Keep the remote job snapshot and the stored artifact record distinct. A job can remain succeeded while one artifact copy temporarily fails. That distinction avoids showing a misleading render failure when only storage delivery needs another attempt.
| Manifest field | Purpose |
|---|---|
| job_id and output_index | Identify the source result |
| source_type | Reject an unexpected output modality |
| copy_status | Track pending, copying, verified, or failed |
| storage_key | Refer to your application-owned object |
| byte_length and sha256 | Verify content integrity |
| owner_reference | Enforce authorization when serving the asset |
Use a unique constraint on the job identifier and output index in your own database. Repeated terminal snapshots should schedule the same artifact copy instead of creating a growing collection of duplicate objects.
Collect a local staging copy
The following shell commands download a source URL you have already validated and compute a checksum. Run them in a staging directory. They do not create a generation job, and the source URL should not contain the Genace Bearer credential.
curl --fail --location --max-time 120 \
--output video.part "$GENACE_OUTPUT_URL"
test -s video.part
sha256sum video.part > video.sha256
ffprobe -v error -show_entries format=duration,format_name \
-of json video.partUse the download validation workflow before renaming or uploading the staged file. Once verified, upload it with your object storage’s authenticated client, then record the storage key and checksum. The storage client and credentials belong to your infrastructure; Genace does not expose an upload-to-your-bucket option through the generation body shown here.
Make publication atomic from the user’s perspective
Do not mark the asset available before its storage write and manifest update succeed. If a worker crashes after upload but before saving the record, a deterministic object key lets the next attempt inspect the existing object and finish reconciliation. Keep failed staging files out of the publicly served location.
Avoid claiming a specific expiration period for source URLs unless the provider contract you actually use documents it. Likewise, the current video adapters can return an empty metadata object, so do not assume width, height, or duration is present there. Inspect the downloaded media when those properties matter.
Verification checklist
Simulate a successful render followed by a download failure, an upload failure, and a crash after upload. Confirm that each recovery reuses the original output and never calls generation again. Verify authorization on the final asset and compare its stored checksum with the staging file.
See job states and production checks for the surrounding workflow.
Continue with production operations
Where these facts come from
- codebase: src/ai/providers/types.ts
- codebase: src/ai/jobs/http.ts
- codebase: src/ai/providers/seedance.ts
- Editorial keyword hypothesis; search volume not measured