Delete File
Delete a file: purge its vectors, delete the object, soft-delete the row.
Ordering is load-bearing and fail-closed on the first step:
- Qdrant points — retrieval filters on the Qdrant payload, NOT this table, so vectors that outlive the row would keep serving the document’s content in search. A failure here aborts with 5xx and the row stays live, so the client can retry; the alternative (mark deleted, leave vectors) is a delete that silently didn’t delete.
- GCS object — best-effort by design (delete_gcs_object never raises). The signed download URL is already unreachable once the row is gone, and a stranded blob is a storage cost, not a disclosure.
- The row — soft-deleted so usage_events.file_id stays resolvable for billing history.
Every step is idempotent and the whole handler is safely retryable, which is what makes a failure recoverable rather than terminal. The final purge runs AFTER deleted_at is committed, so if Qdrant is down at that moment the row is already hidden — a retry that could not see it would 404 forever and leave any vectors an in-flight worker wrote stranded and searchable. So the lookup here deliberately includes soft-deleted rows: a retry re-runs the purge and converges. An unknown file_id is still a 404; an already-deleted one is 204.
Authorizations
Enter your MeshAPI key (rsk_...) — sent as Authorization: Bearer <key>.
Headers
Dated version of the API contract to pin this request to. Omit it and the request is served under 2026-08 — the oldest supported version, so an existing integration is never moved by a release. A malformed or unsupported value is rejected with 400 invalid_api_version rather than falling back silently. The version actually served is echoed as X-Mesh-Version on every response, including errors.
2026-08 Path Parameters
Response
Successful Response