> ## Documentation Index
> Fetch the complete documentation index at: https://cortex-e852fafe-auto-update-openapi-6a9e3873a7492d091ac8c1f.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Delete Context

> Delete knowledge or memories by their IDs.

export const Field = ({name, type, required, recommended}) => {
  const label = required ? 'required' : recommended ? 'recommended' : null;
  const typeLabel = typeof type === 'string' ? type : null;
  const ariaParts = [name, typeLabel && `${typeLabel}`, label].filter(Boolean);
  return <span aria-label={ariaParts.join(', ')} className={label ? 'field-wrap has-field-tip' : 'field-wrap'} style={{
    position: 'relative',
    cursor: label ? 'default' : undefined
  }} tabIndex={label ? 0 : undefined}>
      <span className="field-name-row">
        <code>{name}</code>
        {required && <span className="field-req"> *</span>}
        {recommended && <span className="field-rec"> ●</span>}
      </span>
      {type && <span className="field-type">{type}</span>}
      {label && <span className="field-tip" role="tooltip">
          {label}
        </span>}
    </span>;
};

Specify the resource category with the `type` parameter:

* `type=knowledge` *(default)*  -  delete knowledge sources.
* `type=memory`  -  delete memories.

Pass one or more IDs in `ids`. Send `database`, `collection`, `ids`, and `type` as top-level fields in the request body.

### Knowledge deletion

Use `type: "knowledge"` and pass knowledge `ids` in the `ids` array. Include the same `collection` you used when ingesting the knowledge; omitting it targets the default collection.

<RequestExample>
  ```python Python SDK theme={null}
  client.context.delete(
      type="knowledge",
      database="acme_corp",
      collection="team_docs",
      ids=["policy_main", "runbook_deploy"],
  )
  ```

  ```typescript TypeScript SDK theme={null}
  await client.context.delete({
    type: "knowledge",
    database: "acme_corp",
    collection: "team_docs",
    ids: ["policy_main", "runbook_deploy"],
  });
  ```

  ```bash cURL theme={null}
  curl -X DELETE 'https://api.hydradb.com/context' \
    -H "Authorization: Bearer <your_api_key>" \
    -H "API-Version: 2" \
    -H "Content-Type: application/json" \
    -d '{
      "database": "acme_corp",
      "collection": "team_docs",
      "ids": ["policy_main", "runbook_deploy"],
      "type": "knowledge"
    }'
  ```
</RequestExample>

<ResponseExample>
  ```json Success theme={null}
  {
    "success": true,
    "data": {
      "success": true,
      "message": "Delete completed",
      "results": [
        { "id": "policy_main", "deleted": true },
        { "id": "runbook_deploy", "deleted": true }
      ],
      "deleted_count": 2
    },
    "error": null,
    "meta": {
      "request_id": "9d13aef4-02f4-4e73-8c62-4c2601d04f9d",
      "latency_ms": 12.3
    }
  }
  ```
</ResponseExample>

### Memory deletion

Use `type: "memory"` and pass memory `ids` in the `ids` array. Include the same `collection` you used when ingesting the memories; omitting it targets the default collection.

<RequestExample>
  ```python Python SDK theme={null}
  client.context.delete(
      type="memory",
      database="acme_corp",
      collection="user_alex",
      ids=["mem_user_alex_tone"],
  )
  ```

  ```typescript TypeScript SDK theme={null}
  await client.context.delete({
    type: "memory",
    database: "acme_corp",
    collection: "user_alex",
    ids: ["mem_user_alex_tone"],
  });
  ```

  ```bash cURL theme={null}
  curl -X DELETE 'https://api.hydradb.com/context' \
    -H "Authorization: Bearer <your_api_key>" \
    -H "API-Version: 2" \
    -H "Content-Type: application/json" \
    -d '{
      "database": "acme_corp",
      "collection": "user_alex",
      "ids": ["mem_user_alex_tone"],
      "type": "memory"
    }'
  ```
</RequestExample>

<ResponseExample>
  ```json Success theme={null}
  {
    "success": true,
    "data": {
      "success": true,
      "message": "Successfully deleted 1 memory source(s)",
      "results": [
        { "id": "mem_user_alex_tone", "deleted": true }
      ],
      "deleted_count": 1,
      "user_memory_deleted": 1
    },
    "error": null,
    "meta": {
      "request_id": "9d13aef4-02f4-4e73-8c62-4c2601d04f9d",
      "latency_ms": 12.3
    }
  }
  ```

  ```json 404 - nothing matched (strict mode) theme={null}
  {
    "success": false,
    "data": {
      "success": false,
      "message": "No sources were deleted",
      "results": [
        {
          "id": "mem_user_alex_tone",
          "deleted": false,
          "error": "Memory not found or deletion failed"
        }
      ],
      "deleted_count": 0,
      "user_memory_deleted": 0
    },
    "error": {
      "code": "NOT_FOUND",
      "message": "No sources were deleted"
    },
    "meta": {
      "request_id": "9d13aef4-02f4-4e73-8c62-4c2601d04f9d",
      "latency_ms": 4.8
    }
  }
  ```
</ResponseExample>

## Status codes

**By default, every outcome returns `200`** - including a delete that removed
nothing. The real result is in the body, so check `data.deleted_count` and
`data.results[]` rather than the status code.

```bash Default - always 200 theme={null}
curl -X DELETE 'https://api.hydradb.com/context' \
  -H "Authorization: Bearer <your_api_key>" \
  -H "API-Version: 2" \
  -H "Content-Type: application/json" \
  -d '{ "database": "acme_corp", "ids": ["policy_main"], "type": "knowledge" }'
```

### Opt in to honest status codes

Send `X-HydraDB-Delete-Status: strict` and a delete that did not happen returns
`404`, `409`, or `500` instead of `200`. **This is the recommended mode for new
integrations** - it is the only way to detect a failed delete from the status
code alone.

```bash Strict - honest status codes theme={null}
curl -X DELETE 'https://api.hydradb.com/context' \
  -H "Authorization: Bearer <your_api_key>" \
  -H "API-Version: 2" \
  -H "X-HydraDB-Delete-Status: strict" \
  -H "Content-Type: application/json" \
  -d '{ "database": "acme_corp", "ids": ["policy_main"], "type": "knowledge" }'
```

In strict mode:

| Status | Code                | Meaning                                                                                     |
| ------ | ------------------- | ------------------------------------------------------------------------------------------- |
| `200`  | n/a                 | At least one source was deleted. Check `results[]` for per-ID outcomes.                     |
| `404`  | `NOT_FOUND`         | None of the given `ids` matched anything to delete.                                         |
| `409`  | `SOURCE_PROCESSING` | A source is still indexing. Retry after ingestion completes - see the `Retry-After` header. |
| `500`  | `INTERNAL_ERROR`    | A store failed to remove the source. The delete is retryable.                               |

<Warning>
  Deleting a source that is still indexing is the case worth handling, and the
  main reason to turn strict mode on. Ingestion is asynchronous, so an
  ingest-then-delete sequence - what most teardown and test scripts do - can
  reach the source before it finishes indexing. The source is **not** deleted.

  In the default mode that comes back as a `200` with `deleted_count: 0`, which
  is exactly the silent failure that leaves data behind. In strict mode it is a
  `409`. Retry once indexing completes, or poll
  [Source Status](/api-reference/v2/endpoint/source-status) first.
</Warning>

On `404`, `409`, and `500` the response `data` still carries the same
`results` / `deleted_count` payload a `200` carries, so you can read per-ID
outcomes on a failure exactly as you would on success:

```json 409 - still indexing (strict mode) theme={null}
{
  "success": false,
  "data": {
    "success": false,
    "message": "Source is still processing; retry deletion after ingestion completes",
    "results": [
      {
        "id": "policy_main",
        "deleted": false,
        "error": "Source is still processing; retry deletion after ingestion completes"
      }
    ],
    "deleted_count": 0
  },
  "error": {
    "code": "SOURCE_PROCESSING",
    "message": "Source is still processing; retry deletion after ingestion completes"
  },
  "meta": {
    "request_id": "9d13aef4-02f4-4e73-8c62-4c2601d04f9d",
    "latency_ms": 8.1
  }
}
```

### Which mode you get

The header always wins. Without it, the server default applies.

| Request                           | Behaviour                                                            |
| --------------------------------- | -------------------------------------------------------------------- |
| No header                         | The server default - currently `legacy`, so `200` for every outcome. |
| `X-HydraDB-Delete-Status: strict` | Honest `404` / `409` / `500`.                                        |
| `X-HydraDB-Delete-Status: legacy` | `200` for every outcome, whatever the server default.                |

<Note>
  **The default is expected to become `strict` in a future release.** Adopting
  `strict` now means that change is a no-op for you.

  When it happens, `X-HydraDB-Delete-Status: legacy` keeps the unconditional
  `200` for any integration that is not ready. Both header values are supported
  and neither has a removal date - if that ever changes, we will announce it.

  If your integration checks `response.ok` or `status == 200` today, it is
  treating blocked deletes as successful. That is the failure strict mode
  surfaces.
</Note>

## Some additional notes

* **Partial-success semantics:** For `type=knowledge`, each ID is reported independently in `results[]`. A failure on one ID does not stop the rest. For `type=memory`, the response reports an aggregate `user_memory_deleted` reflecting *all* listed IDs. One exception: if any source in the request is still indexing, the whole request is refused and nothing is deleted - reported as `409` in strict mode, and as a `200` with `deleted_count: 0` by default.
* **Retrieval drops the source immediately:** Even before background cleanup finishes, deleted IDs disappear from `/query` and `/context/list` responses.
* **Mixed deletes need two calls:** To delete both knowledge and memory items, send two requests  -  one with `type=knowledge`, one with `type=memory`.

<div className="api-before-related-resources" />

<Tip>
  **Related Resources**

  * **Find IDs:** [List Documents](/api-reference/v2/endpoint/list-documents)
  * **Perform a query:** [Query](/api-reference/v2/endpoint/query)
  * **Re-add content:** [Ingest Context](/api-reference/v2/endpoint/ingest-context)
  * **Bigger hammer:** [Delete Database](/api-reference/v2/endpoint/delete-tenant) - removes the entire database
  * **Read more:** [Context Management - Overview](/api-reference/v2/endpoint/sources-overview)
</Tip>


## OpenAPI

````yaml api-reference/v2/openapi.json DELETE /context
openapi: 3.1.0
info:
  contact:
    email: support@hydradb.com
    name: HydraDB Support
  description: >-
    HydraDB Application API — knowledge ingestion, search, and memory
    management.
  license:
    name: Proprietary
  title: HydraDB Application API
  version: 0.1.0
servers:
  - description: Production server
    url: https://api.hydradb.com
security: []
externalDocs:
  description: ''
  url: ''
paths:
  /context:
    delete:
      tags:
        - context
      summary: Delete documents or memories
      description: >-
        Delete one or more knowledge sources or memories by ID.


        By default this endpoint answers 200 for every outcome, including a
        delete

        that removed nothing — check `data.deleted_count` and `data.results`
        rather

        than the status code.


        Send `X-HydraDB-Delete-Status: strict` to opt in to honest status codes:
        a

        delete that did not happen then answers 404/409/500 and never 200. This
        is

        the recommended mode for new integrations. On those failures the
        response

        `data` still carries the same `results` / `deleted_count` payload a 200

        carries, so per-id outcomes stay readable either way.


        The default is expected to become strict in a future release, at which

        point `X-HydraDB-Delete-Status: legacy` keeps the unconditional 200 for
        a

        caller that is not ready.
      parameters:
        - description: >-
            Selects the status behaviour for this request. `strict` opts in to
            honest 404/409/500 codes when the delete did not happen; `legacy`
            forces the unconditional 200. Omitted, the server default applies —
            currently `legacy`.
          in: header
          name: X-HydraDB-Delete-Status
          schema:
            enum:
              - strict
              - legacy
            type: string
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/sources.V2SourceDeleteRequest'
        description: Delete request
        required: true
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: >-
                  #/components/schemas/handler.Envelope-sources_MemoryDeleteResponse
          description: OK
        '400':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/handler.ErrorResponse'
          description: Bad Request
        '404':
          content:
            application/json:
              schema:
                $ref: >-
                  #/components/schemas/handler.ErrorEnvelope-sources_MemoryDeleteResponse
          description: >-
            Strict mode only. No source matched the given ids; `data` carries
            the same results/deleted_count payload a 200 carries
        '409':
          content:
            application/json:
              schema:
                $ref: >-
                  #/components/schemas/handler.ErrorEnvelope-sources_MemoryDeleteResponse
          description: >-
            Strict mode only. Source is still indexing; retry after ingestion
            completes (see Retry-After). `data` carries the same
            results/deleted_count payload a 200 carries
        '500':
          content:
            application/json:
              schema:
                $ref: >-
                  #/components/schemas/handler.ErrorEnvelope-sources_MemoryDeleteResponse
          description: >-
            Strict mode only. A store failed to delete the source; the delete is
            retryable. `data` carries the same results/deleted_count payload a
            200 carries
      security:
        - BearerAuth: []
components:
  schemas:
    sources.V2SourceDeleteRequest:
      properties:
        collection:
          description: >-
            Collection scope. Defaults to the default collection when omitted.
            Formerly `sub_tenant_id`; the `sub_tenant_id` alias is still
            accepted (deprecated).
          example: team_docs
          type: string
        database:
          description: >-
            Database/Collection are the canonical v2 names; TenantID/SubTenantID
            are

            their deprecated aliases, reconciled by the TenantAliases middleware
            before

            binding so TenantID is always populated.
          example: acme_corp
          type: string
        ids:
          description: IDs of the sources or memories to delete.
          example:
            - HydraDoc1234
            - HydraDoc4567
          items:
            type: string
          type: array
          uniqueItems: false
        sub_tenant_id:
          deprecated: true
          description: 'deprecated: use collection'
          example: sub_tenant_4567
          type: string
          x-deprecated: 'true'
        tenant_id:
          deprecated: true
          description: 'deprecated: use database'
          example: tenant_1234
          type: string
          x-deprecated: 'true'
        type:
          deprecated: true
          description: |-
            Deprecated: kept for split databases.
            Type names the corpus: knowledge (default) or memory.
          enum:
            - knowledge
            - memory
            - all
          example: knowledge
          type: string
          x-deprecated: true
      type: object
    handler.Envelope-sources_MemoryDeleteResponse:
      properties:
        data:
          $ref: '#/components/schemas/sources.MemoryDeleteResponse'
          example:
            deleted_count: 1
            message: Success
            results:
              - deleted: true
                error: ''
                id: HydraDoc1234
            success: true
            user_memory_deleted: 1
        error:
          $ref: '#/components/schemas/handler.apiError'
          description: Error message, empty string on success.
          example:
            code: DATABASE_NOT_FOUND
            message: Database not found
        meta:
          $ref: '#/components/schemas/handler.responseMeta'
          example:
            collection: team_docs
            database: acme_corp
            latency_ms: 12.3
            request_id: 9d13aef4-02f4-4e73-8c62-4c2601d04f9d
            source_type: file
            sub_tenant_id: sub_tenant_4567
            tenant_id: tenant_1234
        success:
          description: Whether the request succeeded.
          example: true
          type: boolean
      type: object
    handler.ErrorResponse:
      properties:
        data: {}
        detail:
          $ref: '#/components/schemas/handler.ErrorDetail'
          description: Structured error detail with code, message, and deprecation hints.
          example:
            deprecated: true
            deprecated_field: tenant_id
            error_code: VALIDATION_ERROR
            message: Request validation failed
            preferred_field: database
        error:
          $ref: '#/components/schemas/handler.apiError'
          description: Error message, empty string on success.
          example:
            code: DATABASE_NOT_FOUND
            message: Database not found
        meta:
          $ref: '#/components/schemas/handler.ErrorMeta'
          example:
            latency_ms: 12.3
            request_id: 9d13aef4-02f4-4e73-8c62-4c2601d04f9d
        success:
          description: Whether the request succeeded.
          example: true
          type: boolean
      type: object
    handler.ErrorEnvelope-sources_MemoryDeleteResponse:
      properties:
        data:
          $ref: '#/components/schemas/sources.MemoryDeleteResponse'
          example:
            deleted_count: 1
            message: Success
            results:
              - deleted: true
                error: ''
                id: HydraDoc1234
            success: true
            user_memory_deleted: 1
        detail:
          $ref: '#/components/schemas/handler.ErrorDetail'
          example:
            deprecated: true
            deprecated_field: tenant_id
            error_code: VALIDATION_ERROR
            message: Request validation failed
            preferred_field: database
        error:
          $ref: '#/components/schemas/handler.apiError'
          description: Error message, empty string on success.
          example:
            code: DATABASE_NOT_FOUND
            message: Database not found
        meta:
          $ref: '#/components/schemas/handler.ErrorMeta'
          example:
            latency_ms: 12.3
            request_id: 9d13aef4-02f4-4e73-8c62-4c2601d04f9d
        success:
          description: Whether the request succeeded.
          example: true
          type: boolean
      type: object
    sources.MemoryDeleteResponse:
      properties:
        deleted_count:
          description: Total number of items successfully deleted.
          example: 1
          type: integer
        message:
          description: Human-readable result message.
          example: Success
          type: string
        results:
          description: Per-item results.
          example:
            - deleted: true
              error: ''
              id: HydraDoc1234
          items:
            $ref: '#/components/schemas/sources.SourceDeleteResultItem'
          type: array
          uniqueItems: false
        success:
          deprecated: true
          description: >-
            Deprecated for API clients: whether the REQUEST succeeded is the
            HTTP

            status code, or equivalently the envelope's top-level `success`.
            Whether

            anything was actually removed is deleted_count (0 means the ids
            matched

            nothing) and per-id results[].deleted / results[].error. This flag
            is

            true even for a delete that removed nothing, so it cannot answer
            either

            question on its own. Still emitted unchanged for existing clients

            (PRO-1208).
          example: true
          type: boolean
          x-deprecated: 'true'
        user_memory_deleted:
          description: Number of memory items deleted.
          example: 1
          type: integer
      type: object
    handler.apiError:
      properties:
        code:
          description: Machine-readable error code (e.g. `DATABASE_NOT_FOUND`).
          example: DATABASE_NOT_FOUND
          type: string
        message:
          description: Human-readable description of the error.
          example: Database not found
          type: string
      type: object
    handler.responseMeta:
      properties:
        api_version:
          description: >-
            APIVersion echoes the version of the API that served the request
            (PRO-1209),

            sourced from reqmeta.APIVersion — the same value carried by OpenAPI

            info.version and /health — so a client always knows which API
            version

            produced a response. Always present (no omitempty).
          type: string
        collection:
          description: >-
            Collection scope. Defaults to the default collection when omitted.
            Formerly `sub_tenant_id`; the `sub_tenant_id` alias is still
            accepted (deprecated).
          example: team_docs
          type: string
        database:
          description: >-
            Owning database. Formerly `tenant_id`; the `tenant_id` alias is
            still accepted (deprecated).
          example: acme_corp
          type: string
        deprecation:
          description: >-
            Deprecation lists any migration nudges that apply to this request —
            the

            caller used a legacy /tenants route, a legacy
            tenant_id/sub_tenant_id field,

            or the deprecated sub_tenant_ids selector. It is a non-breaking
            signal (the

            status code is unchanged); omitempty keeps it absent for
            fully-migrated

            requests. A list so independent deprecations coexist without
            clobbering.
          items:
            $ref: '#/components/schemas/handler.deprecationNotice'
          type: array
          uniqueItems: false
        latency_ms:
          description: Server-side processing time in milliseconds.
          example: 12.3
          type: number
        request_id:
          description: Unique identifier for this request, useful for support and tracing.
          example: 9d13aef4-02f4-4e73-8c62-4c2601d04f9d
          type: string
        source_type:
          description: Type of the parent source (e.g. `file`, `slack`, `notion`).
          example: file
          type: string
        sub_tenant_id:
          deprecated: true
          example: sub_tenant_4567
          type: string
          x-deprecated: 'true'
        tenant_id:
          deprecated: true
          example: tenant_1234
          type: string
          x-deprecated: 'true'
      type: object
    handler.ErrorDetail:
      properties:
        deprecated:
          description: Whether this response concerns a deprecated field or route.
          example: true
          type: boolean
        deprecated_field:
          description: The deprecated field name.
          example: tenant_id
          type: string
        error_code:
          description: Machine-readable error classification code.
          example: VALIDATION_ERROR
          type: string
        message:
          description: Human-readable description of the error.
          example: Request validation failed
          type: string
        preferred_field:
          description: The canonical replacement for the deprecated field.
          example: database
          type: string
        success:
          deprecated: true
          description: >-
            Deprecated for API clients: always false on this path, so it carries
            no

            information. To detect a failure read the HTTP status code; for what

            went wrong read the envelope's error.code and error.message, and

            meta.request_id when reporting it. The whole `detail` object is

            deprecated legacy — tagging the field individually so SDK users see
            it

            on the property, not just the container (PRO-1208).
          example: true
          type: boolean
          x-deprecated: 'true'
      type: object
    handler.ErrorMeta:
      properties:
        api_version:
          type: string
        latency_ms:
          example: 12.3
          type: number
        request_id:
          description: Unique identifier for this request, useful for support and tracing.
          example: 9d13aef4-02f4-4e73-8c62-4c2601d04f9d
          type: string
      type: object
    sources.SourceDeleteResultItem:
      properties:
        deleted:
          description: Whether this specific item was deleted.
          example: true
          type: boolean
        error:
          description: Error message for this item, empty string on success.
          example: ''
          type: string
        id:
          description: Unique identifier for this resource.
          example: HydraDoc1234
          type: string
      type: object
    handler.deprecationNotice:
      properties:
        deprecated:
          description: Whether this response concerns a deprecated field or route.
          example: true
          type: boolean
        deprecated_field:
          description: The deprecated field name.
          example: tenant_id
          type: string
        deprecated_since:
          description: API version when the field was deprecated.
          example: 2.0.1
          type: string
        message:
          description: Migration guidance message.
          example: tenant_id is deprecated; use database instead.
          type: string
        preferred_field:
          description: The canonical replacement for the deprecated field.
          example: database
          type: string
      type: object
  securitySchemes:
    BearerAuth:
      bearerFormat: API key
      description: 'API key sent as a Bearer token: "Bearer prefix.secret"'
      scheme: bearer
      type: http

````