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.
Voir le cycle de vie de l’utilisateur final pour attacher un nom d’affichage/email au tenant opaque, le contrat d’effacement RGPD et la manière dont la rétention automatique traite l’activité des connecteurs.
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.