Ce qu’elle fait
- Save —
POST /api/v1/memoriesenregistre une observation pour un utilisateur final. Dédupliquée par contenu. Import en lot jusqu’à 100 à la fois avec/memories/batch. - Search —
POST /api/v1/search: correspondances classées en moins d’une seconde sur la mémoire d’un utilisateur. À utiliser lorsque votre propre agent effectue le raisonnement et n’a besoin que de matière première pertinente. - Deep recall —
POST /api/v1/recall: une réponse synthétisée et étayée par des citations (« que savons-nous de cet utilisateur en lien avec X ») conçue pour être injectée dans un system prompt au début de session. - Suggestions —
POST /api/v1/suggestions: à partir d’un moment de contexte, jusqu’à 5 prochaines actions concrètes, chacune étayée par une mémoire spécifique — jamais de conseils génériques. Renvoie[]pour les nouveaux utilisateurs, donc affichez de manière conditionnelle et récupérez en async. - Ingestion par connecteurs — 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 appartenant à une source
Si vous synchronisez des mémoires depuis un système de référence (lignes de CRM, champs de profil, tickets), utilisez la surface de cycle de vie versionnée : les upserts et suppressions portent uneversion, de sorte que les livraisons hors ordre et les retries après crash sont sûrs par construction. Lisez le guide des mémoires appartenant à une source.
Cycle de vie et conformité
DELETE /api/v1/memories/by-id/{memoryId}— retirer une mémoire.DELETE /api/v1/containers/{containerTag}— supprimer les mémoires d’une source pour un utilisateur.DELETE /api/v1/users/{endUserId}— effacement GDPR complet d’un utilisateur final.
Deux façons de consommer
- API HTTP partenaire (cette section + Référence de l’API) — mémoire pour les utilisateurs de votre produit.
- MCP — les agents de codage utilisent directement la mémoire Conare. Voir outils MCP.