Was es kann
- Save –
POST /api/v1/memoriesspeichert eine Beobachtung für einen Endnutzer. Dedupliziert nach Inhalt. Batch-Import bis zu 100 auf einmal mit/memories/batch. - Search –
POST /api/v1/search: gerankte Treffer im Sekundenbruchteil über die Memory eines Nutzers. Nutze es, wenn dein eigener Agent das Reasoning übernimmt und einfach nur relevantes Rohmaterial braucht. - Deep Recall –
POST /api/v1/recall: eine synthetisierte, zitatbasierte Antwort („was wissen wir über diesen Nutzer relevant zu X”), gedacht zum Injizieren in einen System-Prompt am Session-Start. - Suggestions –
POST /api/v1/suggestions: in einem Kontextmoment bis zu 5 konkrete nächste Aktionen, jeweils in einer konkreten Memory verankert – nie generischer Rat. Liefert[]für neue Nutzer, also rendere bedingt und lade asynchron. - Connector-Ingest – Endnutzer verbinden ihre Tools (Integrations) und ihre Memory füllt sich von selbst, organisiert in per-source Container.
Source-owned Memories
Wenn du Memories aus einem System of Record synchronisierst (CRM-Zeilen, Profilfelder, Tickets), nutze die versionierte Lifecycle-Oberfläche: Upserts und Deletes tragen eineversion, sodass out-of-order Zustellungen und Crash-Retries konstruktionsbedingt sicher sind. Lies den Source-owned-Memories-Guide.
Lifecycle & Compliance
DELETE /api/v1/memories/by-id/{memoryId}– eine Memory entfernen.DELETE /api/v1/containers/{containerTag}– Memories einer Quelle für einen Nutzer löschen.DELETE /api/v1/users/{endUserId}– vollständiger DSGVO-Wipe eines Endnutzers.
Zwei Nutzungsarten
- Partner-HTTP-API (dieser Abschnitt + API-Referenz) – Memory für die Nutzer deines Produkts.
- MCP – Coding-Agents nutzen Conare-Memory direkt. Siehe MCP-Tools.