Memory model

Three things determine what a Memory API request can see: the credential, the host, and any scope in the request body.

Resolution order

The credential decides the memory

A per-memory key (mk_) is bound to one memory. A tenant key (ck_live_) can address any memory in the tenant.

The host can name the memory

A request to a memory's own hostname targets that memory. On the shared host, pass memory_id — or omit it and get the active workspace's primary memory.

The body narrows within the memory

vault_id restricts to a department; space_id restricts to a space. Neither can widen what the credential already permits.

Scope cannot be widened from the client

If a credential is space-scoped, passing a different space_id does not change what it reaches. Scope is injected server-side.

This is worth internalising when designing a client: you cannot implement "let the user pick a space" by passing the chosen space with a broadly-scoped key and trusting the parameter. Either the credential is scoped, or the scope is advisory.

Choosing a host

curl https://api.uni-flow.ai/api/v1/memory/search \
  -H "x-api-key: ck_live_..." \
  -H "content-type: application/json" \
  -d '{"query": "...", "memory_id": "csmbx-wsp_a1b2c3d4"}'

Server-side application code, where one credential legitimately spans several memories.

Scoping a search

memory_idstring

Which memory. Defaults to the active workspace's primary memory.

vault_idstring

Restrict to one department, e.g. v_sales.

space_idstring

Restrict to one space. Ignored if the credential is already space-scoped.

sourcesstring[]

Restrict to specific connected sources, e.g. ["notion", "gmail"].

Scope deliberately

Narrowing improves precision and latency — but an over-narrow filter produces a confident "no information found" when the answer was one department away.

Scope when you know the answer is in there. When you do not, search wide and let reranking do its job.

Memory model

On this page