Ce qu’elle fait
- Enregistrer —
POST /api/v1/memoriesstocke une observation pour un utilisateur final. Dédupliqué par contenu. Import en batch jusqu’à 100 à la fois avec/memories/batch. - Rechercher —
POST /api/v1/search: correspondances classées en moins d’une seconde sur la mémoire d’un utilisateur. À utiliser quand votre propre agent effectue le raisonnement et n’a besoin que de matière première pertinente. - Rappel approfondi —
POST /api/v1/recall: une réponse synthétisée étayée par des citations (« que sait-on de cet utilisateur en rapport avec X ») conçue pour être injectée dans un prompt système au démarrage de session. - Suggestions —
POST /api/v1/suggestions: étant donné un instant de contexte, jusqu’à 5 actions concrètes suivantes, chacune ancrée dans une mémoire spécifique — jamais des conseils génériques. Renvoie[]pour les nouveaux utilisateurs, alors affichez de manière conditionnelle et récupérez en asynchrone. - Ingestion par connecteur — les utilisateurs finaux connectent leurs outils (intégrations) et leur mémoire se remplit d’elle-même, organisée en conteneurs par source.
Mémoires détenues par la source
Si vous synchronisez des mémoires depuis un système d’enregistrement (lignes CRM, champs de profil, tickets), utilisez la surface de cycle de vie versionnée : les upserts et suppressions portent uneversion, si bien que les livraisons hors ordre et les tentatives après crash sont sûres par construction. Lisez le guide des mémoires détenues par la source.
Cycle de vie et conformité
DELETE /api/v1/memories/by-id/{memoryId}— supprimer une mémoire.DELETE /api/v1/containers/{containerTag}— supprimer les mémoires d’une source pour un utilisateur.DELETE /api/v1/users/{endUserId}— effacement RGPD complet d’un utilisateur final.
Deux façons de consommer
- API HTTP partenaire (cette section + Référence API) — mémoire pour les utilisateurs de votre produit.
- MCP — les agents de codage utilisent la mémoire Conare directement. Voir outils MCP.