Core memory operations
Delete a memory
Forget one memory, or erase it with erase=true. Forgetting closes the facts only that memory stated: the memory drops out of every read, and the closed facts stay as history. An erase removes it for good.
/v1/memories/{memory_id}
SDK: korely.delete(memory_id). Forgetting a
memory sets its deleted_at
and closes (sets invalid_at on) the
open facts that only this memory
stated. A fact another memory also states stays open: it only loses this
memory from source_memory_ids. Without erase the
rows stay in the database. The memory's text no longer comes back from any
endpoint except its history, which keeps
the deleted event, and the facts it closed stay readable with
as_of or include_invalidated=true on
Get facts. To erase
everything about an end user use
Forget a user, which deletes
the rows. The guide explains when
to use which.
Authentication
HTTP header, required: Authorization: Bearer kor_live_.... The key must carry the memories:write permission.
Path parameter
This endpoint takes no request body.
| Parameter | Type | Required | Description |
|---|---|---|---|
memory_id | string | Required | The memory id to forget (mem_ and 32 hex characters, or the bare UUID). |
Query parameter
| Parameter | Type | Required | Description |
|---|---|---|---|
erase | boolean | Optional | Default false. true erases the memory for good (erasure): the row, its text and vector, the facts only it stated, the name aliases those facts alone taught Korely, and its item in a /v1/batch payload. A memory forgotten earlier can be erased too. The receipt then has status erased, erasure: "permanent" and facts_deleted. A value that is not a boolean is a 422. The SDKs' delete() does not send it: erasing one memory is REST only. The encrypted backups of the Cloud keep a copy for up to 35 days. |
Example request
curl -X DELETE https://api.korely.ai/v1/memories/mem_8f2c1aab4d7e4f0c9a1b2c3d4e5f6a7b \ -H "Authorization: Bearer kor_live_..."Response
200 OK. A small receipt: what was done, how many facts were
closed or given back, and a receipt id. The Python (0.1.28) and Node (0.1.17)
SDKs return id, status,
facts_invalidated and audit_id only; read
facts_reopened from the REST response.
{ "id": "mem_8f2c1aab4d7e4f0c9a1b2c3d4e5f6a7b", "status": "forgotten", "facts_invalidated": 2, "facts_reopened": 0, "audit_id": "aud_5d3e9f0a1b2c4d6e8f9a0b1c2d3e4f5a"}| Field | Type | Description |
|---|---|---|
id | string | Public memory id (mem_) that was forgotten. |
status | string | forgotten, or erased with erase=true. |
facts_invalidated | integer | Facts closed (invalid_at set) because this memory was their only source. 0 when the memory stated none, when its facts were already closed, or when another memory also states every fact it stated. |
facts_reopened | integer | Facts that a newer fact from this memory had closed and that are true again because the memory is gone: each comes back as a new open fact with a new created_at, and the closed row stays in the history. No model is called. 0 when nothing was given back, for example when another live memory still states the newer value, no live memory states the older one, or another value of the same subject and relation is open. A fact told to several agents of one end user is one row in each agent's namespace: each agent gets its copy back, and facts_reopened counts every copy (since 1.0.8; before, only the first agent's copy came back and the count was 1). Always present, also when 0. |
erasure | string | Only with erase=true: permanent. |
facts_deleted | integer | Only with erase=true: the facts deleted because this memory was their only source. |
audit_id | string | The id of the audit record of this delete, a receipt for your logs. No /v1 route reads that record back, and the audit log lists your API calls, not this record. |
Errors
| Status | Code | Cause |
|---|---|---|
401 | invalid_key | Missing or invalid kor_live_ key in the Authorization header. |
403 | forbidden | The key lacks the memories:write scope required to delete a memory. |
404 | not_found | The memory_id is malformed, no such memory is visible to the key (another project, or another end user for a confined key), or it was already forgotten. A second erase of an erased memory is also a 404. |
422 | invalid_request | erase is not a boolean. |
429 | rate_limit_exceeded | Past the rate limit. Wait as long as Retry-After says. |
500 | internal_error | The server failed on this request; the message holds no detail. Read the memory again before you retry. |
503 | unavailable | The database did not answer, or another change to the same records, such as an erasure under way, held this request more than 5 seconds. Retry after the seconds in Retry-After. |
Notes
- Forget by default. Without
erase, the memory'sdeleted_atis set and the facts only it stated are closed (theirinvalid_atis set). Because Korely is bi-temporal, the rows are kept: the memory drops out of every read, and the closed facts stay reachable viaas_of. Witherase=truethe rows are deleted. - Write scope required. The key must carry
memories:write; a read-only key gets a403. - The request is always logged. The call is recorded in the audit log before the not-found check runs, so even a forget against an unknown id leaves an event, with result
error. - Repeating a delete. A second plain delete of the same memory returns
404: it is already forgotten. A second erase returns404too. An erase after a plain delete works (200). - Nothing else happens. A delete does not count against your monthly quotas, and neither it nor a reopened fact sends a webhook.
- Other doors. The command
korely delete <id>only forgets. The MCP toolkorely_forget_memoryforgets, or erases when asked to.
Related
- Delete a memory, guide, the narrative walkthrough with context.
- Get facts, confirm which facts dropped out after a forget.
- Add a memory, the write path that created it.