Core operations

Delete a memory

Forget a single memory: the facts only it stated are closed and an audit record is created, all in one call.

Deleting a memory tells Korely to stop surfacing it and the typed facts that only it stated. The memory is not erased: its row stays in the database with deleted_at set and drops out of every read except its history. The audit row (audit_id) records the account, the end user, the memory id, how many facts were closed and when; the key that made the call is in the audit log. For a GDPR Art. 17 erasure use Forget a user (DELETE /v1/users/{end_user}/memories), which physically deletes the rows. Facts only this memory stated are closed (invalidated): they disappear from all default reads but remain queryable if you explicitly pass include_invalidated=true on a facts query. A fact another memory also states stays active.

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[Close the facts only it stated]
  D --> E[Write audit record]
  E --> F["200 OK + audit_id"]

Delete pipeline: the memory is soft-deleted, the facts only it stated are closed, 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.facts_invalidated); // 2
console.log(result.audit_id);          // "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 closed because this memory was their only source. 0 when the memory stated none, or when every fact it stated is also stated by another memory.
`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.
`403`	`forbidden`	The key lacks the `memories:write` scope.
`404`	`not_found`	The id is malformed, no memory with that id exists in this key's project, or the memory was already forgotten by a prior delete. The response body is `{"code":"not_found","message":"Memory not found"}`.
`429`	`rate_limit_exceeded`	Too many requests in the current minute, hour or day for your plan. The response carries `Retry-After` (integer seconds), `X-RateLimit-Limit` and `X-RateLimit-Remaining: 0`. A delete does not count against the monthly write or query quota.

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. A delete does not count against your monthly quotas, only against the per-minute, per-hour and per-day rate limits of your plan. For a bulk compliance wipe of one end user, use the Forget a user operation: one call instead of one per memory.
Audit trail. The audit record (audit_id) is retained after deletion. Keep it in your own logs; for an Art. 17 erasure request use Forget a user.

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