Core operations

Forget a user

Erase every memory and fact held for one end user in the key's project, memories, extracted facts, and graph edges, in a single authenticated call.

When one of your end users exercises their right to erasure, you need to remove everything Korely holds about them: raw memory text, vector embeddings, entity graph edges, and bi-temporal facts. A single DELETE /v1/users/{end_user}/memories call does all of this atomically. Memories and facts are physically deleted, superseded facts included, so nothing can be read back afterwards. The response includes an audit_id you can store as proof that the erasure was performed.

Wire this call directly into your own /delete-account flow. No secondary cleanup step is needed: one HTTP request per project satisfies the Article 17 obligation for everything Korely stores on behalf of that user in that project.

flowchart LR
  A([Your delete-account flow]) -->|DELETE /v1/users/end_user/memories| K[Korely]
  K --> M[Purge memory text<br/>+ embeddings]
  K --> G[Remove graph edges]
  K --> F[Delete all facts<br/>current and superseded]
  K --> AU[Emit audit_id]
  AU --> R([Return receipt])
  M -.-> R
  G -.-> R
  F -.-> R

Request

Endpoint: DELETE /v1/users/{end_user}/memories. SDK: korely.delete_all(user_id=...).

Example

from korely_memory import Korely

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

result = korely.delete_all(user_id="customer-4812")

print(result.user_id)             # customer-4812
print(result.memories_deleted)    # 47
print(result.facts_deleted)       # 12
print(result.audit_id)            # aud_5f0c...e8f, store this for your GDPR records

import { Korely } from "korely-memory";

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

const result = await korely.deleteAll({ user_id: "customer-4812" });

console.log(result.user_id);            // customer-4812
console.log(result.memories_deleted);   // 47
console.log(result.facts_deleted);      // 12
console.log(result.audit_id);           // aud_5f0c...e8f, store this for your GDPR records

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

korely delete-all --user-id customer-4812 --yes

# forgot user customer-4812  (47 memory(ies), 12 fact(s) erased, audit aud_5f0c...e8f)

Response

{
  "user_id": "customer-4812",
  "memories_forgotten": 47,
  "facts_invalidated": 12,
  "memories_deleted": 47,
  "facts_deleted": 12,
  "erasure": "permanent",
  "audit_id": "aud_5f0c2d9e8b7a4c1d9e3f6a2b1c0d4e8f"
}

Errors

Every error returns the same envelope: {"code": "<slug>", "message": "<text>"}. There is no error or detail field. Note there is no 404 for an unknown user, forget is idempotent and returns 200 with zero counts (see Notes below).

Notes

• Idempotent. If the user has no memories, the call succeeds and returns the same response shape with counts of zero and a fresh audit_id. Any end_user value is accepted; an unknown or empty one returns 200 with zero counts. It is safe to call from a delete-account handler without a pre-flight existence check.
• Scoped to the key's project. The call erases the end user across every agent_id in the project the key belongs to. If you keep the same end user in several projects, call it once per project, with that project's key.
• Facts are deleted, not invalidated. Erasure is a different operation from the bi-temporal supersede: every fact about the end user is removed, including superseded ones, and include_invalidated cannot bring them back. The audit record keeps the counts and your user_id, never the erased content, so you can evidence the erasure (Article 5(2)).
• Rate-limit behaviour. The endpoint does not count against the monthly write or query quota, so an erasure request never fails because a quota is spent. It is subject to the per-minute, per-hour and per-day rate limits of your plan; that 429 carries a Retry-After header (integer seconds).
• Store the audit_id. The aud_-prefixed receipt is your proof of erasure. Attach it to your internal GDPR erasure record alongside the timestamp of the HTTP response.

Related

• Add a memory, write the first memories for a user.
• Get context, retrieve relevant memories and facts before a forget to audit what will be erased.
• List users, enumerate all end_user identifiers in the key's project to build a deletion queue.
• API reference, full endpoint contract, request/response schemas, and OpenAPI spec.