> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mirobody.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Subjects

> DELETE /v1/subjects/{user} — erase everything for one Subject (right to be forgotten).

## Endpoint

```http theme={null}
DELETE /v1/subjects/{user}
Authorization: Bearer mb_live_*
```

Erases **everything** your account holds for one Subject — the full right to be forgotten in a single call: their health records are **hard-deleted** (rows physically removed), their files and conversations are **soft-deleted** (gone from the API surface), and the `(your account, user)` → Subject mapping is dropped so the identity becomes unreachable.

```bash theme={null}
curl -X DELETE "https://mirobody-api.thetahealth.ai/v1/subjects/alice" \
  -H "Authorization: Bearer $MIROBODY_API_KEY"
```

<Note>
  An erase never creates the very Subject it is erasing: resolution looks up the existing mapping only. Passing a `user` your account has never used returns `404` — nothing is minted.
</Note>

Response:

```json theme={null}
{ "status": "ok", "subject": "alice", "deleted": { "records": 12, "files": 3 } }
```

| Field             | Description                             |
| ----------------- | --------------------------------------- |
| `status`          | `"ok"` on success.                      |
| `subject`         | The `user` that was erased.             |
| `deleted.records` | Structured health records hard-deleted. |
| `deleted.files`   | Files soft-deleted.                     |

## What gets erased

One call covers the whole `/v1` surface for that Subject:

1. **Structured records** — everything written via [`POST /v1/data`](/en/api-reference/data) or stored extractions ([`POST /v1/extract`](/en/api-reference/extract) with `store=true`), regardless of `retention`.
2. **Files** — everything uploaded via [`POST /v1/files`](/en/api-reference/files).
3. **Conversations** — stored responses and sessions from the [Agent API](/en/api-reference/responses).
4. **The identity mapping** — the Subject itself becomes unreachable. A later request that passes the same `user` [mints a fresh, empty Subject](/en/api-reference/overview#multi-tenancy-the-user-field) with no connection to the erased one.

For **finer-grained** deletion, use the per-piece levers instead: `DELETE /v1/data` (records), `DELETE /v1/files/{key}` (one file), `DELETE /v1/responses/{id}` (one stored conversation), [`DELETE /v1/sessions/{id}`](/en/api-reference/sessions) (one session's scope). See [Compliance](/en/api-reference/compliance) for the full user-rights picture.

## Errors

| HTTP  | When                                                                       |
| ----- | -------------------------------------------------------------------------- |
| `404` | Your account has no Subject for this `user` — including one already erased |