The entire public Mnemix API is three endpoints:
POST /v1/recall_and_enrich— the hot path. Who is this, what do we know, enrich the gaps.POST /v1/calls/end— the write-back. Record what happened so next time starts warmer.GET /v1/caller/{phone_number}— the read. Profile fetch with no side effects.
That's it. This is not a beta limitation — it's the design.
Surface area is a tax
Every endpoint you publish is a promise you maintain forever: docs, SDK methods, versioning, deprecation politics. Memory APIs in particular grow baroque — write APIs, query DSLs, graph traversals, embedding knobs. Each one transfers complexity from the vendor to you.
We inverted it. The complexity — enrichment vendor racing, caching, summarization, bi-temporal versioning — lives behind the three calls. Your integration is: call one thing when the phone rings, call one thing when it ends.
The lifecycle is the API
A voice interaction has exactly three moments where memory matters: when you need context (ring), when you produce context (hang-up), and when you want to inspect it (anytime). The API maps one-to-one onto those moments. There's nothing to architect. If your stack can make two HTTP calls, it has memory.
What we left out
No raw vector store access. No embedding management. No query language. If you need a general-purpose memory toolkit, good ones exist. Mnemix is the opposite bet: a complete loop for the voice hot path, small enough to integrate in an afternoon and stable enough to never think about again.