Delete API reference for public file URL cleanup
Use `DELETE /v1/files/{file_id}` after a workflow has finished with the public URL and the file should stop resolving.
- Reviewed by
- GetFileURL technical team
- Updated
- Method
- DELETE
- Path
- https://api.getfileurl.com/v1/files/{file_id}
- Auth
- Authorization: Bearer <api_key>
- Shortcut
- delete_url from upload response
What this page answers
Use DELETE https://api.getfileurl.com/v1/files/{file_id} with bearer authentication.
- Reviewed by
- GetFileURL technical team
- Last updated
Use the file ID returned by upload.
The delete endpoint is part of the lifecycle contract. It should be called by the account that created or controls the file.
file_id
Required path parameter from the upload response.
delete_url
Ready API URL returned by upload for the same cleanup action.
Authorization
Bearer API key for the workspace or account that owns the file.
Timing
Call delete after the destination API has fetched or processed the public URL.
Deletion should be simple for automation branches.
Workflow builders need responses that are easy to branch on and safe to retry.
204 deleted
The file was deleted, public access was revoked, and private bytes were purged or already unavailable.
202 delete_pending
Public access was revoked, but private byte purge is still pending. The response includes `file_id`, `status`, and `request_id`.
401 unauthorized
Missing or invalid API key.
404 not_found
The file ID does not exist, is already removed, or is not visible to the current API key.
Confirm the public URL no longer works after cleanup.
Delete is complete only when later workflow branches stop treating the URL as reusable. Keep this check in QA and support runbooks.
Delivery check
After delete, the public CDN URL should stop resolving for normal downstream fetches.
Metadata check
A file metadata lookup can show lifecycle status such as `deleted`, `expired`, or another terminal state when available.
Retry-safe branch
If cleanup runs twice, treat `404 not_found` as an acceptable already-clean state when the original delete succeeded.
Delete after the final consumer has the file.
Some APIs fetch URLs asynchronously. Deleting immediately after submitting a URL can break the destination service.
Wait for confirmation
Run cleanup after the destination returns success or after a safe delay.
Handle retries
Keep delete steps idempotent so retrying a cleanup branch does not create noise.
Log file IDs
Store file IDs with workflow job IDs for support and audit context.
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
Which endpoint deletes a file?
Use `DELETE https://api.getfileurl.com/v1/files/{file_id}` with bearer authentication.
What response should a successful delete return?
A successful delete returns `204 No Content`. If public access is revoked but private byte purge is still pending, the API can return `202` with `status: delete_pending`.
Where do I get the delete URL?
The upload response includes `delete_url`. Store it with `file_id` and call it after the destination system no longer needs the file.
Can delete be retried safely?
The intended workflow behavior is retry-safe cleanup, where already-deleted files do not break the whole automation.