Polling Video Status Before Download Into a Privately Controlled Bucket

When generating a video for a customer support campaign, treat the process as a submitted job rather than a completed video. Poll the status with exponential backoff and a timeout, only after which obtain the download URL. Store the video bytes in a private bucket controlled by your team before deleting any provider-side asset. This boundary preserves moderation decisions while avoiding the slow renderer from being part of the request path.

Treat each phase separately: submission, rendering, copying, and storage. Use durable states like submitted, rendering, copying, and stored in your own database, and record the provider job ID and idempotency key at submission. Stop polling after a reasonable deadline and enter a failed state if the rendering times out. Never attach the API bearer token to the presigned download URL; treat it as a separate authority.

Only mark storage as complete after the private destination has accepted the object. Keep the moderation gate in place before submission, and validate the uploaded file's actual content rather than trusting its extension or MIME type. Implement the handoff as a resumable worker using the same base URL and key for generation and storage, supplying idempotency keys on writes, honoring Retry-After, and never forwarding that key to the download URL. Generate production request types from the discovery schema instead of guessing optional fields.