Skip to main content

Integration

Die dauerhafte Grenze zwischen deinem Produkt und Conare. Eine Integration gehört deiner Organisation; getrennte Deployment-Stufen (Staging, Prod) sind separate Integrations, disambiguiert per Slug. Jede hat ihren eigenen cint_...-Key mit expliziten Scopes (memory:read, memory:write, memory:delete).

Endnutzer

Jeder Memory-Aufruf nennt eine endUserId (1–128 Zeichen, A-Za-z0-9@._-) – dein Bezeichner für deinen Nutzer. Sie ist kein Namespace: Der physische Mandant ist ein opaker HMAC, abgeleitet aus deiner Integration und der Endnutzer-ID. Clients können weder Namespaces auswählen noch einen anderen Mandanten adressieren – konstruktionsbedingt.
  • Setze die Anzeigeidentität mit PUT /api/v1/users/{endUserId} (Name/E-Mail für deine Dashboard-Ansichten).
  • DELETE /api/v1/users/{endUserId} ist ein vollständiger DSGVO-Wipe dieses Nutzers.

Container

Container gruppieren die Memories eines Nutzers nach Quelle – z. B. profile, claude-chats, saved oder je eine pro verbundener Datenquelle (Container-Tag = Connector-ID). Nutze containerTag beim Speichern zur Organisation und DELETE /api/v1/containers/{containerTag}, um die Memories einer Quelle zu löschen, ohne den Rest anzurühren.

Retrieval-Modi

Fehler und Observability

Fehler nutzen einen stabilen Envelope – { statusCode, code, message, requestId, details? } – und geben niemals interne Mandanten-IDs oder Backend-Texte preis. Jede Response enthält X-Request-Id; sende deine eigene, um End-to-End zu korrelieren. Rate Limits werden mit Standard-Headern und 429 signalisiert; Pläne mit Usage-Ledger signalisieren ein erschöpftes Kontingent mit 402 samt Balance- und Reset-Metadaten.