Temporary URL vs permanent file URL
A temporary file URL is reachable only for a defined job window. A permanent URL stays public until you remove it. The right choice depends on how long the downstream system needs to fetch the file.
- Reviewed by
- GetFileURL technical team
- Updated
- Temporary URL
- Best for OCR, AI, imports, and one-job handoffs
- Permanent URL
- Best for public assets that should stay reachable
- Signed URL
- Best when your app owns storage permissions directly
What this page answers
No. A signed URL usually grants time-limited access to your own storage object. A temporary hosted file URL packages upload, public delivery, expiry, and delete behavior for the workflow.
- Reviewed by
- GetFileURL technical team
- Last updated
Use temporary URLs when the file exists for a job.
Most automation files are intermediate artifacts: an invoice for OCR, an image for moderation, a report for a CRM import, or a generated PDF for one API call.
Short access window
Use the returned `expires_at` to confirm the URL survives queues, retries, and asynchronous destination fetches.
Cleanup by default
Keep `file_id` so the workflow can delete access as soon as the downstream system confirms processing.
Lower public exposure
Avoid leaving workflow-generated files publicly reachable after the job no longer needs them.
Use permanent URLs only for intentionally public assets.
A permanent URL can be useful for public images, documentation downloads, or assets that many systems should fetch over time. It is a poor default for private workflow handoffs.
Public asset fit
Use a long-lived URL when the file is meant to be embedded, shared, or referenced repeatedly.
Governance needed
Permanent URLs need ownership, abuse handling, deletion paths, and clear account policy.
Avoid accidental archives
Do not turn temporary workflow outputs into unmanaged public storage.
Choose the shortest useful lifetime.
Downstream APIs need enough time to fetch the file, but not unlimited time. The best default is a temporary URL with an explicit expiry and an early delete path.
Use 15m to 1h
Fast synchronous processing, small OCR jobs, or immediate AI calls.
Use 24h to 7d
Queued jobs, review flows, social publishing, delayed retries, or customer handoffs.
Use permanent only by intent
Public assets, documentation downloads, or files that are deliberately part of a long-lived public page.
Common questions
Is a temporary file URL the same as a signed URL?
No. A signed URL usually grants time-limited access to your own storage object. A temporary hosted file URL packages upload, public delivery, expiry, and delete behavior for the workflow.
How long should a temporary file URL last?
Use the shortest window that survives the destination system's fetch timing. Immediate API calls may need minutes; queued or retrying workflows may need a day or more.
Can I make a temporary URL permanent later?
Only do that when the file is meant to be a durable public asset. For workflow artifacts, create a new controlled upload or extend retention deliberately.