Migrate from Mem0

If you built on Mem0, the Korely API will feel familiar. The verbs are the same: add a memory, search memories, list them, delete them. The scoping is the same: user_id identifies your end user, agent_id identifies your application, run_id identifies a session. Switching is mechanical: map the calls, replay the corpus through the batch endpoint, verify with a search.

Concept mapping

Mem0 and Korely share the same scoping vocabulary. The table below maps each Mem0 concept to its Korely equivalent so you know what to keep, what to rename, and what is new.

Call mapping

Every core Mem0 call has a direct Korely equivalent, in the Python SDK and over REST. The full REST contract is in the API reference.

The scoping parameters carry over with the same names and the same semantics. user_id is your end user's identifier, free-form, and end users are unlimited on every tier. agent_id namespaces your application. run_id sub-scopes one session. Filters are additive.

In code, the switch looks like this:

# before
from mem0 import MemoryClient
m = MemoryClient(api_key="...")
m.add("Prefers invoices as PDF", user_id="customer-4812")

# after
from korely_memory import Korely
korely = Korely(api_key="kor_live_...")
korely.add("Prefers invoices as PDF", user_id="customer-4812")

results = korely.search("invoice preferences", user_id="customer-4812")

Python and Node.js today.

Gotchas

The surface is familiar, but a handful of parameter names and behaviours differ. Check these before running your migration.

Step 1: export from Mem0

Use the Mem0 platform export API: create an export job, then fetch the JSON payload when it completes. The export contains one object per memory with the text under memory, plus the user_id and metadata you stored. That shape maps onto the Korely batch payload almost field for field.

Step 2: import with the batch endpoint

POST /v1/batch accepts up to 500 memory objects per request, same shape as POST /v1/memories, processed asynchronously. You get a job id back and poll it until it completes. Each imported item runs the full write pipeline: document and chunk embeddings, entity extraction on our own infrastructure, typed-fact extraction with contradiction checking and bi-temporal validity. About a tenth of a cent of intelligence per memory, all included in your plan.

import json, requests

export = json.load(open("mem0_export.json"))

memories = [
    {
        "content": item["memory"],
        "user_id": item.get("user_id"),
        "metadata": item.get("metadata", {}),
    }
    for item in export["results"]
]

# POST /v1/batch takes up to 500 memories per request
for i in range(0, len(memories), 500):
    r = requests.post(
        "https://api.korely.ai/v1/batch",
        headers={"Authorization": "Bearer kor_live_..."},
        json={"memories": memories[i : i + 500]},
    )
    print(r.json())  # {"id": "job_4e1aa0", "status": "processing", "received": 500}

Poll the job until it reports completed:

curl https://api.korely.ai/v1/batch/job_4e1aa0 \
  -H "Authorization: Bearer kor_live_..."

# 200 OK
{"id": "job_4e1aa0", "status": "completed", "imported": 500, "failed": 0}

Step 3: verify with search

Pick a query you know your old corpus can answer and run it scoped to one end user. Memory search is semantic vector retrieval — cosine similarity over embeddings. The only model call on the read path is the query embedding, a fraction of a hundredth of a cent. No generative model composes the output. Your agent's own model does the reasoning over the results. For recall assembled from the typed-fact layer rather than raw snippets, reach for GET /v1/context — see below.

curl -X POST https://api.korely.ai/v1/memories/search \
  -H "Authorization: Bearer kor_live_..." \
  -H "Content-Type: application/json" \
  -d '{"query": "invoice preferences", "user_id": "customer-4812", "limit": 5}'

# 200 OK
{
  "results": [
    {"id": "mem_3fa1c9", "score": 0.91,
     "snippet": "Prefers invoices as PDF, replies fastest before 10am CET.",
     "user_id": "customer-4812", "agent_id": null,
     "metadata": {"source": "mem0_export"}}
  ]
}

Extraction runs on ingest, so the graph and the fact store fill in as the batch completes. A GET /v1/facts call against a migrated entity confirms the typed layer is populated.

What your agents gain

A typed knowledge graph

Every imported memory goes through entity extraction. People, companies, products, places, and concepts become nodes; relations between them become typed edges, drawn from canonical predicates grouped into families (preferences, people, places, work, ownership, health, financial, events, and an other bucket for predicates outside the named groups). The graph is queryable: GET /v1/facts?entity=... returns every typed fact touching an entity — its neighbourhood in the graph — so you can walk from any subject to what it is connected to. These reads are deterministic SQL with zero AI calls, reusing stored vectors rather than computing new embeddings.

# list all memories for a user (SDK)
memories = korely.get_all(user_id="customer-4812")

# or over REST
# GET /v1/memories?user_id=customer-4812&limit=20
# check the graph layer with GET /v1/facts?user_id=customer-4812
# {"facts": [{"subject": "customer-4812", "predicate": "likes", "predicate_raw": "prefers",
#             "object": "PDF invoices", "predicate_family": "preferences", "invalid_at": null, ...}], "total": 1}

See the graph for a full explanation of how entities connect memories and how to traverse those connections over the REST API.

Bi-temporal facts

Each memory also yields typed (subject, predicate, object) triples, and every triple carries valid_from and invalid_at. When new information contradicts an existing fact, a two-stage contradiction check at write time invalidates the old fact and keeps it as history. Default reads return only what is true now; pass include_invalidated=true for the full supersede chain, or as_of on GET /v1/facts for a point-in-time view. Facts reads are deterministic SQL, typically under 50 ms, and return flat JSON — {"facts": [...], "total": N} — with each fact's raw verb preserved in predicate_raw alongside the normalized predicate. The temporal engine runs on every tier, and GET /v1/facts / korely.get_facts() work on every plan, free hobby tier included. The full model is in temporal facts.

Memory your end users can see

Korely ships a desktop and web app where the human sees the same memory your agents use. The Memory Panel lists every fact; each one can be edited or forgotten (erasure with audit cascade), and an Entity Profile drawer shows everything known about one entity. A fact a user erases there does not come back to agents, on any read path. If agents carry long-term memory about people, the people get the delete button. Read human in the loop for the full model.

Underneath all three: reads are retrieval, not generation. The intelligence runs once, at write time, which is why read quotas are an order of magnitude more generous than write quotas. Quotas for each plan are on the pricing page.

Next steps

• Quickstart: wire Korely into your stack and run your first search in five minutes.
• API reference: the complete REST contract behind every call in the mapping table.
• Architecture: where the write-time intelligence runs and why the read path stays deterministic.
• Questions about a large corpus or an unusual export shape? Email [email protected]. We read every message.