Skip to main content
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:
Oder mit dem SDK:
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.
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.
DELETE erfolgt immer sofort und betrifft stets den gesamten Nutzer – unabhängig von deiner Retention-Richtlinie. Es gibt keinen Soft-Delete und keine Karenzzeit.

​
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.