Delete User Memories
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.
Request
- Base URL: https://api.korely.ai
- URL: https://api.korely.ai/v1/users/{end_user}/memories
- Auth: HTTP bearer
Path parameters
Response
Successful Response
Changes
No recorded changes to this operation across all 1 revision of this API.