Genace
Sign inGet started

reference image URL expiration: cover asynchronous provider access

A signed reference URL can work during form validation and expire before the generation provider retrieves it. The relevant window includes your application’s dispatch delay and the provider’s asynchronous access timing. Genace’s current adapters forward the first reference URL, but they do not publish a universal minimum signed-URL lifetime or a promise that the provider downloads it immediately.

Preserve the asset, not only the signed URL

Store an immutable asset identity, validated content type, and ownership record in your application. Generate a read URL for that asset when your dispatch policy is ready to use it. A short-lived URL pasted into a queue days before processing is a fragile substitute for a durable asset reference.

Keep the exact bytes stable while the operation is active. Replacing an object under the same storage key can make a retried access retrieve a different reference even if the URL still works. Use versioned or immutable storage identifiers when reference consistency matters.

{
  "asset_id": "application-reference-18",
  "validation_state": "ready",
  "storage_version": "immutable-version-3",
  "access_policy": "generation-reference",
  "operation_id": "application-operation-42"
}

This is a local asset record, not a Genace request body. Resolve it to image_inputs only at the submission boundary, and keep the resulting signed URL in restricted storage if recovery needs the exact submitted value.

Budget access time deliberately

Choose a validity window based on measured dispatch delay, expected provider access behavior, and your storage security policy. Include clock differences and operational margin. Do not present a convenient example interval as a documented Genace requirement.

For storage-signed URLs, effective validity can depend on the signing credential’s lifetime as well as the requested expiration. Review your storage provider’s documentation and credential configuration. A URL with a later timestamp is not guaranteed usable if its underlying temporary credentials have already expired or access has been revoked.

Validate through the intended access path

Check the exact URL without browser cookies or an interactive session. Confirm it returns image bytes through the network path the provider can use, rather than an HTML login page or a private-network hostname. Apply your own destination policy if your backend performs a validation fetch.

Avoid checking only HEAD when the signature or storage policy was issued for GET. Use a method permitted by the signed URL and limit transferred bytes according to your validation design. A successful preflight still cannot guarantee the URL remains valid at every later moment.

Recover without guessing provider timing

If a job fails with an access-related symptom, preserve the submitted asset version, URL expiry metadata, job ID, and actual error. Do not assume every failure is caused by expiry or automatically resubmit with a longer URL. Verify the reference independently and reconcile accounting before authorizing new work.

Acceptance checks

Test an already expired URL, a temporary credential that expires early, and a queue delay longer than your initial policy. Confirm validation fails before submission where possible. Verify active references remain immutable and signed URLs do not appear in public logs.

See reference inputs, upload validation, and log redaction.

Continue with security

Where these facts come from