---
title: "Delete User Memories"
method: DELETE
path: "/v1/users/{end_user}/memories"
tags: ["v1"]
---

# Delete User Memories

`DELETE /v1/users/{end_user}/memories`

## Request

- Base URL: `https://api.korely.ai`
- URL: `https://api.korely.ai/v1/users/{end_user}/memories`
- Auth: HTTP bearer

ERASE everything about one end user in one call: every memory and fact.

Physical deletion, not a flag: after this call the content is gone from the
database and cannot be read back by any parameter, `include_invalidated`
included. Unrecoverable by design, because that is what erasure means.

`end_user` is the `user_id` exactly as written, percent-encoded as one path
segment (`acme/42` is `acme%2F42`). Any stored id is accepted here,
including one written before new ids were required to be a single segment.

The response counts rows physically deleted: `memories_deleted` and
`facts_deleted` (until 0.1.42 also under their first names,
`memories_forgotten` and `facts_invalidated`, removed in 0.2.0).

The audit row survives, carrying counts and a keyed pseudonym of your
`end_user_id`, none of the erased content, so you can evidence the erasure
to your own regulator: `GET /v1/audit?user_id=<the same id>` finds it. The
rest of the access trail takes the pseudonym too, the cost rows lose the
end user, and a webhook already delivered takes the pseudonym.

Within the key's project: the same id in another project of the account
stays there (it may be another customer's person). To erase it in every
project at once, the account's administrator calls
`DELETE /admin/users/{end_user}/memories`.

For a single memory, `DELETE /v1/memories/{memory_id}` forgets it (out of
every read, the row kept, and no call brings it back) or, with
`erase=true`, erases it.

## Path parameters

- `end_user` string, required

## Response `200`

Successful Response

- UserErasureResponse: DELETE /v1/users/{end_user}/memories: what was physically deleted. Field order is the order on the wire.
  - `user_id` string, required: The end user that was erased.
  - `memories_deleted` integer, required: Memories physically deleted.
  - `facts_deleted` integer, required: Facts physically deleted.
  - `erasure` string, required: Always `permanent`.
  - `audit_id` string, required: The `aud_` id of the audit row, which keeps the counts and a keyed pseudonym of your end user id, never the erased content.

## Other responses

- `401`: `invalid_key`: the `Authorization: Bearer` key is missing, unknown, revoked or expired.
- `403`: `forbidden`: the key lacks the scope this operation needs; `message` names it.
- `422`: `invalid_request`: the body, a query parameter or a path parameter is malformed (`detail` is the list of fields that failed, `message` names the first), or the endpoint refuses a value (an empty content, an unreadable timestamp; `detail` is a sentence or `{code, message}`).
- `429`: `rate_limit_exceeded`: past the request ceiling, the per-minute one set on this install (`RATE_LIMIT_PER_MINUTE`) or, on the hosted service, the plan's minute, hour or day; `message` names the window and `Retry-After` the seconds until it resets.
- `500`: `internal_error`: the server failed on this request; `message` holds no detail of it.
- `503`: A dependency did not answer: the database while the key was checked (`unavailable`, see `Retry-After`), or the one `code` names. Nothing was written; retry.

---

[API](https://skmtc.dev/korely/apis/korely-agents-api.md) · [All operations](https://skmtc.dev/korely/apis/korely-agents-api/llms.txt) · [OpenAPI document](https://skmtc.dev/korely/apis/korely-agents-api/revisions/8a40bf09eca1?raw)