Skip to main content
Chaque appel de mémoire nomme un endUserId — votre identifiant stable pour votre utilisateur (1–128 caractères, A-Za-z0-9@._-). Conare ne le stocke jamais en clair : le tenant physique est un HMAC opaque dérivé de votre intégration et de l’identifiant, et l’isolement s’appuie toujours sur ce hachage. Cette page couvre les deux opérations de cycle de vie qui vous appartiennent — l’étiquetage et la suppression — ainsi que la manière dont la rétention automatique interagit avec les connecteurs.

​
Attacher une identité d’affichage

Par défaut, la liste des utilisateurs finaux de votre tableau de bord affiche des hachages opaques. Envoyez un nom d’affichage et/ou un email pour que la liste montre des personnes plutôt que des hachages :
Ou avec le SDK :
Sémantique :
  • Purement cosmétique. L’endUserId reste haché par HMAC côté Conare ; la récupération, l’isolement et la facturation s’appuient toujours sur le hachage. Cette étiquette ne change que ce que vous voyez dans la liste.
  • Mises à jour partielles. Envoyez une chaîne pour définir un champ, null pour l’effacer, omettez la clé pour la laisser inchangée. Fournissez au moins l’un de name ou email.
  • Limites. name jusqu’à 120 caractères, email jusqu’à 254 caractères (forme vérifiée pour @ ; pas de vérification de délivrabilité — l’hygiène des adresses de vos utilisateurs vous appartient).
  • Non facturé. L’appel est gratuit et n’est pas comptabilisé comme activité d’utilisateur final, donc étiqueter un utilisateur dormant ne prolongera pas sa fenêtre de rétention.
Quand l’utiliser : appelez-le dès que vous connaissez déjà une identité d’affichage pour un utilisateur — par exemple juste après son inscription, ou lorsque vous livrez l’intégration pour la première fois et souhaitez rétroactivement étiqueter les utilisateurs existants. C’est optionnel ; l’omettre laisse simplement la liste afficher des hachages.

​
Supprimer un utilisateur final (effacement RGPD)

DELETE /api/v1/users/{endUserId} est une suppression complète et irréversible. Câblez-la dans votre flux de suppression de compte.
En un seul appel, Conare :
  1. Révoque d’abord les ressources du plan connecteur — les jetons OAuth et les ressources de connecteur propres à l’utilisateur sont démontés avant l’effacement de la mémoire. Si le plan connecteur est injoignable, l’appel renvoie 503 pour que vous puissiez réessayer ; un effacement qui aurait laissé un jeton OAuth actif serait une fausse réussite.
  2. Efface le plan mémoire — chaque mémoire, chaque vecteur, chaque conteneur de cet utilisateur.
  3. Supprime l’état des connecteurs — l’état de connecteur par utilisateur qui sert à reprendre les synchronisations incrémentales.
  4. Retire la ligne de la liste — l’utilisateur disparaît de votre tableau de bord d’utilisateurs finaux.
Les synchronisations en arrière-plan en cours ne peuvent pas ressusciter un utilisateur supprimé. Si une synchronisation de connecteur tourne au moment de la suppression, elle est interrompue en pleine exécution plutôt que d’écrire dans le tenant effacé.
DELETE est toujours immédiat et concerne toujours l’utilisateur entier, quelle que soit votre politique de rétention. Il n’y a pas de suppression logique ni de période de grâce.

​
Rétention automatique

Sous Platform → Retention, vous pouvez définir une fenêtre d’inactivité maximale. Une fois une fenêtre configurée, Conare purge automatiquement tout utilisateur final inactif plus longtemps que celle-ci — une purge exécute le même démontage complet qu’un DELETE /api/v1/users/{endUserId} explicite (plan mémoire, état des connecteurs, ligne de la liste, révocations OAuth). Ce qui compte comme activité :
  • Tout appel de l’API partenaire qui nomme l’utilisateur — y compris les lectures (search, recall, suggestions) et les écritures (memories, containers).
  • Les synchronisations de connecteurs comptent comme activité. Un utilisateur avec un connecteur actif est conservé jusqu’à ce que vous le déconnectiez. Si vous voulez que la rétention automatique s’applique aux utilisateurs connectés, déconnectez d’abord le connecteur (ou supprimez l’utilisateur explicitement).
Ce qui ne compte pas comme activité :
  • PUT /api/v1/users/{endUserId} (définition de l’identité d’affichage) — étiqueter un utilisateur dormant ne prolonge pas la rétention.
  • Les consultations de la liste dans le tableau de bord.
Laissez le champ vide pour conserver les utilisateurs indéfiniment. Les requêtes DELETE explicites s’exécutent toujours immédiatement, quels que soient les réglages de rétention.