Intégration
La frontière durable entre votre produit et Conare. Une intégration est détenue par votre organisation ; les étapes de déploiement distinctes (staging, prod) sont des intégrations séparées, désambiguïsées par un slug. Chacune possède sa propre clécint_... avec des portées explicites (memory:read, memory:write, memory:delete).
Utilisateurs finaux
Chaque appel de mémoire nomme unendUserId (1–128 caractères, A-Za-z0-9@._-) — votre identifiant pour votre utilisateur. Ce n’est pas un namespace : le tenant physique est un HMAC opaque dérivé de votre intégration et de l’identifiant d’utilisateur final. Par construction, les clients ne peuvent pas sélectionner de namespace ni adresser un autre tenant.
- Définissez l’identité d’affichage avec
PUT /api/v1/users/{endUserId}(nom/email pour vos vues de tableau de bord). DELETE /api/v1/users/{endUserId}est un effacement RGPD complet de cet utilisateur.
Conteneurs
Les conteneurs regroupent les mémoires d’un utilisateur par source — par exempleprofile, claude-chats, saved, ou un par source de données connectée (étiquette de conteneur = id du connecteur). Utilisez containerTag à l’enregistrement pour organiser, et DELETE /api/v1/containers/{containerTag} pour supprimer les mémoires d’une source sans toucher au reste.
Modes de récupération
Erreurs et observabilité
Les erreurs utilisent une enveloppe stable —{ statusCode, code, message, requestId, details? } — et ne divulguent jamais d’identifiants de tenant internes ni de texte backend. Chaque réponse inclut X-Request-Id ; envoyez le vôtre pour corréler de bout en bout. Les limites de taux sont signalées par les en-têtes standard et 429 ; les plans à registre d’usage signalent un quota épuisé avec 402 accompagné de métadonnées de solde/réinitialisation.