Core operations

Forget a user

Erase every memory and fact held for one end user, 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. Facts are invalidated rather than deleted outright, so the audit trail stays intact while the data stops being served. The response includes a signed 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 satisfies the Article 17 obligation for everything Korely stores on behalf of that user.

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[Invalidate all facts<br/>valid_from / invalid_at]
  K --> AU[Emit audit_id]
  AU --> R([Return receipt])
  M -.-> R
  G -.-> R
  F -.-> R

Forget invalidates facts and removes memory data; the audit record persists for your compliance logs.

Request

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

Parameter	Type	Required	Description
`end_user`	string (path)	Required	The `user_id` you use when writing memories. Identifies the data subject whose data will be erased. Must match the value passed to `add()` for that user.
`Authorization`	header	Required	`Bearer kor_live_...`, your agent API key. The key must belong to the agent that owns the user's memories.

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_forgotten)  # 47
print(result.facts_invalidated)   # 12
print(result.audit_id)            # aud_3d0f, 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_forgotten); // 47
console.log(result.facts_invalidated);  // 12
console.log(result.audit_id);           // aud_3d0f, 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

# user_id:            customer-4812
# memories_forgotten: 47
# facts_invalidated:  12
# audit_id:           aud_3d0f

Response

{
  "user_id": "customer-4812",
  "memories_forgotten": 47,
  "facts_invalidated": 12,
  "audit_id": "aud_3d0f"
}

Field	Type	Description
`user_id`	string	The end user that was erased, echoed back for confirmation.
`memories_forgotten`	integer	Number of memory records purged (text, embeddings, and graph edges removed).
`facts_invalidated`	integer	Number of bi-temporal facts invalidated. Facts are not mutated; `invalid_at` is set so they stop being served while the audit trail stays intact.
`audit_id`	string	A signed receipt you can attach to your own GDPR erasure record. Prefixed `aud_`.

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).

Status	Code	When it happens
`401`	`invalid_key`	The `Authorization` header is missing, malformed, or the key has been revoked. Message: `Invalid or missing API key`.
`422`	`invalid_request`	The `end_user` path segment failed validation, for example, an empty string. Message format: `<field>: <reason>`. This endpoint takes no request body.
`429`	`quota_exceeded`	The agent has exhausted its monthly query quota. Forget calls count toward the query quota, not the write quota. If the limit is a per-window rate limit, the response carries a `Retry-After` header (integer seconds).

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. It is safe to call from a delete-account handler without a pre-flight existence check.
Scoped to your agent key. Only memories and facts written under the same kor_live_... key are erased. If the same end user exists in multiple agents, each agent must call this endpoint independently.
Facts are invalidated, not deleted. Bi-temporal facts have their invalid_at timestamp set to now. They stop being served in /context and /facts responses, but the audit trail (including the fact that a fact existed) is preserved for your own GDPR records. This satisfies Article 17 because the personal data is no longer processed.
Rate-limit behaviour. The endpoint is subject to the query quota of your plan. Hobby: 25 k queries/month; Developer: 250 k; Team: 1 M; Scale: 10 M. A monthly-quota 429 (quota_exceeded) does not carry a Retry-After header; only a per-window rate-limit 429 does (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.

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 your agent to build a deletion queue.
API reference, full endpoint contract, request/response schemas, and OpenAPI spec.