File URL expiry and retention for workflow handoffs
File URL retention should match the job. A URL needs to live long enough for the destination to fetch it, then expire or be deleted when public access is no longer needed.
- Reviewed by
- GetFileURL technical team
- Updated
- Immediate API call
- Minutes to one hour can be enough
- Queued workflow
- Use a longer window for retries and async processing
- Sensitive files
- Prefer short expiry plus delete after processing
What this page answers
Use the shortest window that covers the destination fetch, async processing, retries, and any required human review.
- Reviewed by
- GetFileURL technical team
- Last updated
Choose a lifetime based on when the destination fetches the file.
Some APIs fetch immediately. Others queue imports, retry later, or process asynchronously. Expiry should cover the real fetch window.
Minutes
Fast one-step OCR, AI, or validation calls where the destination fetches immediately.
Hours or days
Queued workflows, social publishing, CRM imports, human review, or delayed retry branches.
Permanent only by intent
Use long-lived URLs only for public assets that should remain available.
Delete early when the workflow confirms the file is no longer needed.
Expiry is the automatic backstop. Delete is the explicit cleanup action when the destination confirms it fetched or processed the file.
Store file_id
The upload response should keep the cleanup handle separate from the public URL.
Wait for final consumer
Do not delete immediately after submitting a URL if the destination imports asynchronously.
Handle retries
Retry branches should know whether they can still use the URL or need a new upload.
Retention defaults should reflect file risk.
Public file URLs are intentionally reachable. Sensitive files, customer documents, and private workflow outputs should default to short lifetimes and visible cleanup paths.
Sensitive content
Use the shortest working lifetime and delete after processing.
Operational logs
Log `expires_at`, `file_id`, source workflow, and destination response status.
No search indexing
Customer-uploaded files should not become indexable content by default.
Common questions
How long should a file URL last?
Use the shortest window that covers the destination fetch, async processing, retries, and any required human review.
Is expiry enough, or should I also delete files?
Expiry is a good default backstop. Delete early when the workflow knows the file is no longer needed.
Should public file URLs be indexed by Google?
No. Product pages and docs should be indexable; customer-uploaded file URLs should not be treated as search content.