Delete a public file URL when the workflow is done
The job is done. Delete the file by ID so the public URL stops resolving before its normal expiry window.
- Reviewed by
- GetFileURL technical team
- Updated
- Create
- POST /v1/files returns file_id
- Use
- Pass url to the downstream API
- Cleanup
- DELETE /v1/files/{file_id} or delete_url
What this page answers
Store the file_id from the upload response and call DELETE /v1/files/{file_id} with your API key.
- Reviewed by
- GetFileURL technical team
- Last updated
Cleanup belongs in the workflow, not in a future manual task.
Public file URLs are useful because downstream APIs can fetch them. Delete is the control that keeps temporary workflow files from becoming forgotten public assets.
After OCR
Delete invoice or document URLs after extraction succeeds and the data is stored.
After publishing
Remove generated media URLs after a social or CMS platform has fetched the file.
After client handoff
Clean up files created for one-time CRM, portal, or support workflows.
The upload response should carry the cleanup handle.
Do not parse a CDN URL to decide what to delete. Store the `file_id` returned by the upload response and use that ID for lifecycle calls.
Authenticated delete
Delete calls should require an API key, not public URL access.
delete_url
Use the returned delete URL when a workflow builder needs a ready cleanup path.
Idempotent behavior
Workflow retries should be able to handle already-deleted files cleanly.
Audit context
Keep source workflow, customer, and job metadata near the file ID for debugging.
Branch on delete responses without guessing.
The delete API is designed for automation cleanup branches. Treat success, pending purge, and missing-file states as expected workflow outcomes.
204 deleted
Public access was revoked and the file is deleted or already unavailable.
202 delete_pending
Public access was revoked, but private byte purge is still waiting for the scheduled retry sweep.
404 not_found
The file ID does not exist, was already removed, or is not visible to the current API key.
Run cleanup after the final consumer confirms the file.
Many destination APIs fetch URLs after accepting a request. Delete too early and the destination may fail when it tries to fetch the file.
Upload
Create the URL with `POST /v1/files` and store `url`, `file_id`, `delete_url`, and `expires_at`.
Confirm
Wait until the OCR, AI, CRM, CMS, or publishing API confirms that it fetched or processed the file.
Delete
Call the delete endpoint, or use the returned `delete_url`, so the public URL stops resolving.
Deletion should make the public URL stop resolving.
After deletion, downstream retries may fail because the file is no longer public. That is expected when cleanup runs too early.
Deleted before fetch
Move cleanup after the destination API confirms it fetched or processed the file.
Wrong file ID
Use the `file_id` from the original upload response, not a filename or URL fragment.
Retry branches
Avoid deleting files before all retry or fallback branches have finished.
Copy the same upload shape into code
curl -X DELETE https://api.getfileurl.com/v1/files/file_8ks41p \
-H 'Authorization: Bearer $GETFILEURL_KEY'Common questions
How do I delete a hosted file URL?
Store the `file_id` from the upload response and call `DELETE /v1/files/{file_id}` with your API key.
Does delete require the public URL?
No. Delete should use the authenticated file ID so public URL viewers cannot remove files.
Can I use delete_url instead of building the path?
Yes. Upload returns a `delete_url` so workflow builders can store a ready cleanup path beside the file ID.
Should I delete every file manually?
Use expiry for automatic cleanup and delete manually when a workflow finishes earlier than the expiry window.