How to Keep AI Music Files After Temporary API URLs Expire

Treat every generated-audio download URL as a handoff, not permanent storage. Copy, verify, and publish only the durable application asset.

Treat every generated-audio download URL as a handoff, not permanent storage. When an async task succeeds, download the file into storage your application controls, reject empty results, calculate a SHA-256 digest, read the stored object back, and expose only your durable application URL to users.

By Sonilo Team · Facts verified August 8, 2026

The distinction matters because signed URLs are time-limited credentials. Amazon S3 and Google Cloud Storage both document signed URLs as temporary access to an object, not ownership of a permanent address. Sonilo's current Retrieve Task documentation likewise describes successful audio and video result URLs as temporary downloads that are valid for seven days.

The safe production pattern

Use two state machines: one for generation and one for your stored asset. A generation can succeed while the application asset is still copying or verifying. Mark the asset ready only after the durable copy passes readback.

This table is the core rule: provider success is not the same as application readiness.

An eight-step handoff from task to durable file

1. Save both task identities

Store the provider's task ID and your own immutable request ID when the generation request is accepted. Keep the video project ID or export revision in the same record so support can trace a soundtrack back to the exact edit that requested it.

2. Poll at the documented interval

The Sonilo async task reference lists processing, succeeded, and failed as native task states and instructs clients to poll every two to five seconds. Polling faster adds load without making the generation complete sooner. Polling much slower increases the delay between provider success and your durable copy.

For the request shape itself, start with the Sonilo video-to-music API guide, then use the live endpoint documentation as the current contract.

3. Validate the result before writing a file

On success, require a non-empty result URL and sensible media metadata. Reject a blank URL, zero-byte response, HTML error page, or unexpected content type. The Sonilo Quickstart explicitly warns against creating placeholder output files when generation fails or when no audio bytes arrive.

4. Copy the bytes server-side

Download the generated media from your backend or controlled worker. Do not make a customer browser responsible for the only permanent copy. Write the bytes to an object key owned by your application, such as a project-scoped path with a stable asset ID.

Do not store the complete signed source URL in logs, analytics, or customer-visible records. Signed URLs carry authentication material in their query strings, and anyone holding an active URL may be able to access the object.

5. Record a byte count and SHA-256 digest

Calculate the digest from the bytes you actually stored, not from the source URL string. NIST FIPS 180-4 defines SHA-256 as a secure hash algorithm that produces a message digest useful for detecting whether data changed.

A digest answers one narrow question: are these bytes still the same bytes? It does not prove ownership, licensing, authorship, or creative quality.

6. Read the durable object back

Perform a real readback before marking the asset ready. Confirm the stored object exists, has the expected content type, has a plausible byte count, and produces the same digest. For higher assurance, decode enough of the file to confirm it is playable audio rather than a correctly hashed error payload.

7. Publish your application URL, not the provider URL

Return a stable asset ID to the rest of your product. Generate your own authorized playback or download URL from that ID when a user needs access. This keeps provider credentials out of the client and lets your application control retention, revocation, and access policy.

8. Preserve the handoff record

Keep the request ID, provider task ID, endpoint, request and success timestamps, source result field, reported and stored byte counts, content type, digest, durable object key, and verification timestamp. Link the record to the exact video export that uses the soundtrack.

If the same music is reused in a new project or channel, also preserve the relevant license evidence. The separate guide on adding music to a video without copyright surprises explains that rights-checking workflow.

Handle failures by class, not with one retry loop

Retrying every error can duplicate charges, hide configuration problems, and create multiple outputs for one user action.

The HTTP Retry-After specification defines the server's minimum requested wait, while the Sonilo docs map common API statuses to distinct error conditions. Your worker should preserve that distinction in logs and product-facing errors.

The minimum durable output record

Use this as the acceptance checklist for every generated soundtrack:

• Internal request ID
• Provider task ID and endpoint
• Video project ID or export revision
• Request and provider-success timestamps
• Source result field and content type
• Reported and stored byte counts
• SHA-256 digest of the stored bytes
• Durable object key
• Readback verification timestamp
• Failure history and retry count

The record is complete when another engineer can identify the request, locate the controlled copy, verify its bytes, and see which video export consumes it without reopening the provider dashboard.

What this workflow does not guarantee

Durable storage does not make an audio file good, unique, licensed for every use, or immune from a platform claim. It solves a narrower engineering problem: preserving the exact generated media your product accepted and preventing an expiring delivery credential from becoming a broken customer asset.

Review the soundtrack before publication. Keep rights evidence beside the project. Apply your own retention, privacy, and access-control rules to both the source video and generated audio.

When Sonilo is not the right fit

Sonilo is designed for teams that start with a finished or near-finished video and want music generated from that footage. It is not the best choice when you need a catalog search for a known song, a human composer under a bespoke agreement, permanent provider-hosted media as your system of record, or an on-premises generation stack. In those cases, use the tool and storage architecture that directly matches the requirement.

If your product already has an edited video and needs a soundtrack workflow, review the Sonilo video-to-music API. Build the durable handoff before the first customer export, not after the first expired link.