A completed media job produces a file. Your application also needs to know where that file is, who can access it and how long it must remain available. Those are three related decisions, with different controls.
A delivery link's expiry is not the file's retention period. Treat the file, its storage location and any temporary access link as separate parts of your workflow.
Choose where the job delivers
Tornado supports managed delivery and customer-configured destinations. Supported integrations include S3-compatible storage, Google Cloud Storage, Azure Blob Storage and Alibaba OSS. Google Drive has a separate configuration path. The options available for a request depend on the integration and account configuration.
Managed delivery is useful for trying a workflow and retrieving its result. If your application needs durable storage under your own lifecycle rules, configure an appropriate destination and test it before sending a large workload.
Storage can be selected through saved configuration or supported per-request options. Verify the API key, destination selection and request actually used for your job. Do not assume that the settings you changed elsewhere apply to every key or integration.
Verify upload and read access
Submit one small job to the intended destination. Confirm that the file appears where you expect, that your consuming application can read it and that its format is usable. An upload permission alone does not establish read access.
The job response can include a delivery URL in the field s3_url. The field name also appears for supported destinations other than S3. Use the returned result rather than trying to construct a URL from the provider name.
Signing support and permissions vary by provider and credentials. If there is no usable delivery URL, inspect the destination reference and use your authorized storage access. A missing or expired link does not, by itself, prove the file is missing.
A signed link is temporary access
A signed delivery URL grants access within its validity and permission constraints. Treat it as sensitive: someone who possesses a working link may be able to read the file. Avoid putting it in public issues, analytics event properties or long-lived public pages.
Delivery URLs commonly have a 24-hour validity, but the actual destination and credentials can shorten or otherwise constrain access. For example, a supplied Azure SAS retains its own expiry and permissions. Do not use a single expiry assumption as the storage policy for your application.
After a link expires, use the supported job or storage access path for that destination. Do not automatically submit another media-processing job: first determine whether the existing file is still available to your authorized storage client.
Decide how long to retain the file
When files are delivered to your own storage, configure the lifecycle and access policies your application needs. Define when the media is deleted, who can read it and which downstream copies your workflow creates.
For managed delivery, confirm the retention terms that apply before relying on it as an archive. Neither an expiry timestamp on a URL nor the presence of a historical job record establishes a permanent hosting commitment.
Keep a stable record in your application: source URL, job ID, destination reference and the result of your next processing step. Store temporary links only for as long as they are needed. If your application deletes a source file, account for any copies already sent to another tool.
Protect the configuration
Use dedicated storage credentials with the permissions documented for your provider and the narrowest scope that supports the workflow. Follow the provider-specific guide; the permissions needed for an upload, cleanup and signed download are not interchangeable.
Keep API keys and storage credentials in server-side secret configuration. When changing or rotating them, test delivery and reading again. Configure webhook signing separately if your application relies on signed notifications: it is a different control from file-access signing.
The custom-storage documentation covers configuration paths and provider details. Read the privacy policy for the service's published data-handling terms, and contact support if your workflow has a retention or access requirement that needs confirmation.
Once those requirements are clear, open the dashboard and test the complete route from a source URL to a file your own application can read.