Korely
Your Dashboard

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. By default the memory is forgotten: its row stays with deleted_at set and drops out of every read except its history. With ?erase=true it is erased for good: the row, its text and vector, and the facts only it stated are deleted, and the response says status "erased", erasure "permanent" and facts_deleted. A memory forgotten earlier can still be erased (a plain repeat delete answers 404). The SDK delete() does not send erase: use the REST call. 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. To erase everything about an end user 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).

ParameterTypeRequiredDescription
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_8f2c1a4d9b3e47a6b05e2c7d1f3a9e84.
erase boolean Optional Query parameter, default false. true erases the memory for good instead of forgetting it, and also works on a memory forgotten earlier.

No request body.

Example

from korely_memory import Korely


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


result = korely.delete("mem_8f2c1a4d9b3e47a6b05e2c7d1f3a9e84")


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

Response

{
  "id": "mem_8f2c1a4d9b3e47a6b05e2c7d1f3a9e84",
  "status": "forgotten",
  "facts_invalidated": 2,
  "audit_id": "aud_3d0f9a21c4b84e6f8a7d5c3b2e1f0a9d"
}
FieldTypeDescription
id string The memory id that was forgotten, echoed back for confirmation.
status string "forgotten" on success, or "erased" with erase=true.
erasure string Only with erase=true. Always "permanent".
facts_deleted integer Only with erase=true. Number of facts physically deleted because only this memory stated them.
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. With erase=true it counts the facts closed by the forget step that runs first, and is 0 if the memory was already forgotten.
audit_id string Identifier of the audit record. Useful if you log deletion events in your own system.

The forgotten memory disappears from POST /v1/memories/search, the MCP korely_search tool and GET /v1/context. The facts it closed disappear from the default reads of GET /v1/facts, GET /v1/profile and GET /v1/context. A facts query still returns them when it asks about the past: with include_invalidated=true, or with an as_of or known_as_of earlier than the delete.

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

StatusCodeCause
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 {"detail":"Memory not found","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). 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 (unless you pass erase=true), 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; to erase everything about an end user use Forget a user.

Related