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

# Endnutzer-Lebenszyklus

> Anzeigeidentität an opake Endnutzer-Mandanten heften, Nutzer mit vollständigem DSGVO-Abriss löschen und verstehen, wie Retention Connector-Aktivität behandelt.

Jeder Memory-Aufruf nennt eine `endUserId` – dein stabiler Bezeichner für deinen Nutzer (1–128 Zeichen, `A-Za-z0-9@._-`). Conare speichert sie niemals im Klartext: Der physische Mandant ist ein opaker HMAC, abgeleitet aus deiner Integration und der ID, und die Isolation greift stets auf den Hash zurück. Diese Seite beschreibt die beiden Lebenszyklus-Operationen, die dir gehören – Beschriftung und Löschung – sowie das Zusammenspiel der automatischen Retention mit Connectors.

## Anzeigeidentität heften

Standardmäßig zeigt die End-Users-Liste in deinem Dashboard opake Hashes. Übergib einen Anzeigenamen und/oder eine E-Mail, damit die Liste Personen statt Hashes zeigt:

```bash theme={null}
curl -X PUT https://api.conare.ai/api/v1/users/u_123 \
  -H "Authorization: Bearer $CONARE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Ada Lovelace", "email": "ada@example.com" }'
```

Oder mit dem SDK:

```ts theme={null}
await conare.setUserIdentity({
  endUserId: "u_123",
  name: "Ada Lovelace",
  email: "ada@example.com",
});
```

Semantik:

* **Rein kosmetisch.** Die `endUserId` bleibt auf Conare-Seite HMAC-gehasht; Retrieval, Isolation und Abrechnung greifen weiterhin auf den Hash zurück. Dieses Label ändert nur, was *du* in der Liste siehst.
* **Partielle Updates.** Sende einen String, um ein Feld zu setzen, `null`, um es zu leeren, oder lass den Key weg, um es unverändert zu lassen. Gib mindestens eines von `name` oder `email` an.
* **Limits.** `name` bis zu 120 Zeichen, `email` bis zu 254 Zeichen (Form auf `@` geprüft; keine Zustellbarkeitsprüfung – die Adresshygiene deiner Nutzer liegt bei dir).
* **Nicht abgerechnet.** Der Aufruf ist kostenlos und zählt nicht als Endnutzer-Aktivität; das Beschriften eines inaktiven Nutzers verlängert dessen Retention-Fenster also nicht.

Wann einsetzen: Rufe das immer dann auf, wenn dir bereits eine Anzeigeidentität für einen Nutzer bekannt ist – zum Beispiel direkt nach der Anmeldung oder wenn du die Integration erstmals ausrollst und Labels für bestehende Nutzer nachziehen möchtest. Es ist optional; überspringst du es, zeigt die Liste weiterhin Hashes.

## Endnutzer löschen (DSGVO-Wipe)

`DELETE /api/v1/users/{endUserId}` ist ein vollständiger, unumkehrbarer Abriss. Verdrahte ihn in deinen Account-Löschprozess.

```bash theme={null}
curl -X DELETE https://api.conare.ai/api/v1/users/u_123 \
  -H "Authorization: Bearer $CONARE_KEY"
```

```ts theme={null}
await conare.deleteUser("u_123");
```

In einem einzigen Aufruf tut Conare Folgendes:

1. **Widerruft zuerst Ressourcen der Connector-Ebene** – alle OAuth-Holds und nutzerbezogenen Connector-Ressourcen werden vor dem Memory-Wipe abgebaut. Ist die Connector-Ebene nicht erreichbar, liefert der Aufruf `503`, damit du erneut versuchen kannst; ein Wipe, der ein lebendes OAuth-Token zurücklässt, wäre ein falscher Erfolg.
2. **Löscht die Memory-Ebene** – jede Memory, jeden Vektor, jeden Container dieses Nutzers.
3. **Verwirft den Connector-State** – den nutzerbezogenen Connector-State, der zum Fortsetzen inkrementeller Syncs dient.
4. **Entfernt die Listenzeile** – der Nutzer verschwindet aus deinem End-Users-Dashboard.

Laufende Hintergrund-Syncs können einen gelöschten Nutzer nicht wiederbeleben. Läuft ein Connector-Sync zum Zeitpunkt der Löschung, bricht der Sync mitten in der Ausführung ab, statt in den gelöschten Mandanten zu schreiben.

<Note>
  `DELETE` erfolgt immer sofort und betrifft stets den gesamten Nutzer – unabhängig von deiner Retention-Richtlinie. Es gibt keinen Soft-Delete und keine Karenzzeit.
</Note>

## Automatische Retention

Unter **Platform → Retention** kannst du ein maximales Inaktivitätsfenster festlegen. Ist ein Fenster konfiguriert, entfernt Conare automatisch jeden Endnutzer, der länger als dieses Fenster inaktiv war – eine solche Bereinigung führt denselben vollständigen Abriss aus wie ein explizites `DELETE /api/v1/users/{endUserId}` (Memory-Ebene, Connector-State, Listenzeile, OAuth-Widerrufe).

Was als Aktivität zählt:

* Jeder Partner-API-Aufruf, der den Nutzer nennt – einschließlich Lesevorgängen (`search`, `recall`, `suggestions`) und Schreibvorgängen (`memories`, `containers`).
* **Connector-Syncs zählen als Aktivität.** Ein Nutzer mit einem aktiven Connector bleibt erhalten, bis du diesen trennst. Soll die automatische Retention auch für verbundene Nutzer greifen, trenne zuerst den Connector (oder lösche den Nutzer explizit).

Was nicht als Aktivität zählt:

* `PUT /api/v1/users/{endUserId}` (Setzen der Anzeigeidentität) – das Beschriften eines inaktiven Nutzers verlängert die Retention nicht.
* Dashboard-Ansichten der Liste.

Lass das Feld leer, um Nutzer dauerhaft zu behalten. Explizite `DELETE`-Requests werden unabhängig von den Retention-Einstellungen stets sofort ausgeführt.