> ## Documentation Index
> Fetch the complete documentation index at: https://developers.meshapi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

  1. 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.
  2. 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.
  3. 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.



## OpenAPI

````yaml /api/openapi.json delete /v1/files/{file_id}
openapi: 3.1.0
info:
  title: MeshAPI
  description: One key, all AI models.
  version: 0.1.0
servers:
  - url: https://api.meshapi.ai
security:
  - BearerAuth: []
paths:
  /v1/files/{file_id}:
    delete:
      tags:
        - RAG
      summary: Delete File
      description: >-
        Delete a file: purge its vectors, delete the object, soft-delete the
        row.


        Ordering is load-bearing and fail-closed on the first step:

          1. 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.
          2. 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.
          3. 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.
      operationId: delete_file
      parameters:
        - name: file_id
          in: path
          required: true
          schema:
            type: string
            title: File Id
        - in: header
          name: X-Mesh-Version
          required: false
          schema:
            type: string
            enum:
              - 2026-08
            default: 2026-08
          example: 2026-08
          description: >-
            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.
      responses:
        '204':
          description: Successful Response
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
      security:
        - BearerAuth: []
components:
  schemas:
    HTTPValidationError:
      properties:
        detail:
          items:
            $ref: '#/components/schemas/ValidationError'
          type: array
          title: Detail
      type: object
      title: HTTPValidationError
    ValidationError:
      properties:
        loc:
          items:
            anyOf:
              - type: string
              - type: integer
          type: array
          title: Location
        msg:
          type: string
          title: Message
        type:
          type: string
          title: Error Type
        input:
          title: Input
        ctx:
          type: object
          title: Context
      type: object
      required:
        - loc
        - msg
        - type
      title: ValidationError
  securitySchemes:
    BearerAuth:
      type: http
      scheme: bearer
      description: >-
        Enter your MeshAPI key (`rsk_...`) — sent as `Authorization: Bearer
        <key>`.

````