Skip to main content
DELETE
Erase End-User Data
People who reach your Guru through a widget, a chat bot or the API do not have a Gurubase account, so they cannot use the account tools to see or delete their data. This endpoint is how the team running the Guru answers their access (GDPR Art. 15) and erasure (Art. 17) requests. Which party is the controller for that data depends on your deployment and your agreement with us; see the privacy policy and your DPA rather than treating this page as the answer. Everything is scoped to the Guru in the path, so a key cannot reach another Guru’s data even for the same end-user id.

Path Parameters

string
required
The Guru the end user interacted with
string
required
The identifier your integration supplied when the questions were asked

Headers

string
required
Your API key. You can obtain one from the Gurubase dashboard.
Choose the mode with the mode query parameter.
string
default:"detach"
detach removes the identifiers from their questions, their rejected questions and their conversations, keeping the question text as your Guru’s analytics history. purge deletes those questions, rejected questions and conversations outright.
detach is the default because it cannot destroy content you did not mean to lose, but it leaves the person’s own words in your Guru. To answer a genuine erasure request in full, use mode=purge.
Stored memories, the stored profile, the semantic search history and any files the person uploaded are deleted in both modes.
The mode only decides what happens to the question text, which is your Guru’s analytics history. A profile is not your content: it is a record built about the person, holding whatever they told the Guru about themselves. Neither is a file they attached, which is their own document. There is no mode that keeps either.
Uploaded files means the stored object itself, not only the row pointing at it: the images, log files and documents attached to their questions are removed from storage, along with the cached description of each image and the debugging record of each log file.
Deleting a file cannot be undone or rolled back, so it happens before the database work. If the request then fails, retry it: the second attempt finds the files already gone and finishes the rest.
memories_cleared is reported separately: if the memory store was unreachable the rows are still gone but the memories are not, and you should retry rather than record the request as complete. To read the same person’s data before erasing it, see Get End-User Data.