Core operations

Delete a memory

Forget a single memory — its derived facts are invalidated and an audit record is created, all in one call.

Deleting a memory tells Korely to stop surfacing it and the typed facts that were extracted from it. The memory itself is not hard-deleted from the database: Korely keeps an audited stub so you have a clear record of when the memory was forgotten and under which API key. This design honours GDPR Art. 17 (right to erasure) while letting you produce an audit log if your product ever needs one. Facts derived from the memory are marked invalidated — they disappear from all default reads but remain queryable if you explicitly pass include_invalidated=true on a facts query.

Call this operation when an end user asks your agent to forget something specific, when a piece of information is confirmed wrong, or when a compliance workflow requires point-in-time removal. To remove everything for one end user at once, see the Forget a user operation (DELETE /v1/users/{end_user}/memories) instead.

flowchart LR
  A["DELETE /v1/memories/{id}"] --> B[Verify ownership]
  B --> C[Soft-delete memory row]
  C --> D[Invalidate derived facts]
  D --> E[Write audit record]
  E --> F["200 OK + audit_id"]

Delete pipeline: the memory is soft-deleted, derived facts are invalidated, and an audit record is written — all atomically.

Request

Endpoint: DELETE /v1/memories/{id}. SDK: korely.delete(memory_id).

Parameter	Type	Required	Description
`Authorization`	string	Required	HTTP header. Value: `Bearer kor_live_...`. Must belong to the workspace that owns the memory.
`id`	string	Required	Path parameter. The memory id returned when the memory was created, e.g. `mem_8f2c1a`.

No request body.

Example

from korely_memory import Korely

korely = Korely(api_key="kor_live_...")

result = korely.delete("mem_8f2c1a")

print(result.status)            # "forgotten"
print(result.facts_invalidated) # 2
print(result.audit_id)          # "aud_3d0f"

import { Korely } from "korely-memory";

const korely = new Korely({ apiKey: "kor_live_..." });

const result = await korely.delete("mem_8f2c1a");

console.log(result.status);           // "forgotten"
console.log(result.factsInvalidated); // 2
console.log(result.auditId);          // "aud_3d0f"

curl -X DELETE https://api.korely.ai/v1/memories/mem_8f2c1a \
  -H "Authorization: Bearer kor_live_..."

# 200 OK
{
  "id": "mem_8f2c1a",
  "status": "forgotten",
  "facts_invalidated": 2,
  "audit_id": "aud_3d0f"
}

Response

{
  "id": "mem_8f2c1a",
  "status": "forgotten",
  "facts_invalidated": 2,
  "audit_id": "aud_3d0f"
}

Field	Type	Description
`id`	string	The memory id that was forgotten, echoed back for confirmation.
`status`	string	Always `"forgotten"` on success.
`facts_invalidated`	integer	Number of typed facts derived from this memory that were marked invalidated. May be 0 if no facts were extracted at write time.
`audit_id`	string	Identifier of the audit record. Useful if you log deletion events in your own system.

Invalidated facts disappear from all default reads — including POST /v1/memories/search, GET /v1/context, and the MCP korely_search tool. They remain retrievable only when you explicitly pass include_invalidated=true on a facts query, which is an advanced auditing feature.

If the memory id does not exist, or belongs to a different workspace, the endpoint returns 404 Not Found. Deleting a memory that has already been forgotten also returns 404 — the delete is not idempotent, so guard against a double call in your own code if you replay requests.

Errors

Status	Code	Cause
`401`	`invalid_key`	The `Authorization` header is missing or the key is invalid / revoked.
`404`	`not_found`	No memory with that id exists in this workspace, or the memory was already forgotten by a prior delete. The response body is `{"code":"not_found","message":"Memory not found"}`.
`422`	`invalid_request`	Request validation failed — most commonly a malformed id path parameter.
`429`	`quota_exceeded`	Monthly write quota exceeded — delete counts against the write quota. Body: `{"code":"quota_exceeded","message":"..."}`. The write-quota 429 carries no `Retry-After` header; the limit resets at the next billing cycle, or upgrade your plan.

Notes

Not idempotent. Deleting a memory that is already in the "forgotten" state returns 404 — the first delete succeeds, a replay fails. If your pipeline retries requests, dedupe deletes on your side.
Workspace scoping. The API key determines the workspace. A memory owned by a different workspace returns 404, not 403, so that workspace membership is not leaked.
End-user scoping. If your memories are tagged with user_id or agent_id at write time, deletion still operates by memory id — there is no filter parameter on this endpoint. To remove all memories for a given end user in a single call, use DELETE /v1/users/{end_user}/memories.
Rate limits. Delete counts against your monthly write quota. If you are running a bulk compliance wipe, pace your requests or use the Forget a user operation which is quota-efficient for mass removal.
Audit trail. The audit record (audit_id) is retained after deletion. You can reference it when responding to GDPR Art. 17 erasure requests.

Forget a user — remove every memory for an end user in one call
Update a memory — correct a memory without deleting it
Search memories — verify a memory no longer appears after deletion
API reference — full endpoint contract including history and batch endpoints