Delete files

Both calls stop the file serving immediately and remove every size built from it.

They are reversible for 30 days. The stored copy is kept and the record survives alongside it, so a file can be brought back exactly as it was — see restoring a deleted file. After 30 days the copy expires and the deletion becomes permanent.

1curl -X DELETE "$BASE/v1/files/abc123def456" \2  -H "authorization: Bearer $KEY"

1{ "success": true }

Deleting something already deleted returns 404, so retrying after a timeout is safe — you cannot delete the wrong thing by repeating yourself.

When one of your objects goes, its files should go with it, without you keeping a list of ids to loop over.

1curl -X DELETE "$BASE/v1/files?entityType=product&entityId=prod_abc123" \2  -H "authorization: Bearer $KEY"

1{ "deleted": 4 }

At least one of entityType, entityId or role is required, and they combine with AND. The operation is scoped to your project, so an entity id that also exists in someone else's cannot widen what it touches.

Matching nothing is not an error — it returns { "deleted": 0 }.

A bare delete is refused, not interpreted

1{ "error": "At least one filter required: entityType, entityId, or role" }

DELETE /v1/files is never read as "everything".

Be careful with role alone

DELETE /v1/files?role=gallery

Valid, and it deletes every gallery image in the project across every product. If you mean one product's gallery, name the product.

This is the call the 30-day window exists for. If it takes out more than you meant, everything it touched is listed at GET /v1/files/deleted.

After deleting

Already-cached copies at the CDN edge can still be served briefly, the same as any other change to what a URL points at. Deleting stops a file being distributed rather than making it instantly unreachable everywhere.

Errors

1{ "error": "File not found" }