App users & tenancy

An app user is one person your app serves. Alexein keeps each app user's memory apart from every other app user's. You name the app user on every request with the X-Alexein-User header.

The header names the app userCopy Anchor Link

Every /v2/memory/* request carries X-Alexein-User. Use the id your app already has for the person, such as user_42.

curl https://api.alexein.ai/v2/memory/search \
  -H "Authorization: Bearer $ALEXEIN_API_KEY" \
  -H "X-Alexein-User: user_42" \
  -H "Content-Type: application/json" \
  -d '{ "query": "What does Alice eat?" }'

The app user is never a field in a request body. Bodies are what a model fills in when it calls memory as a tool. A model that could write an app user's id into a body could name somebody else. A header is set by your code, not by the model.

A request without the header is refused with 400. There is no default app user. Your key decides the organisation and the project, and the header picks the app user inside that project. No header value can reach another organisation's or another project's app users. Error messages name the app user as you sent it.

IsolationCopy Anchor Link

• Each app user's memory is separate. No request for one app user can read, change or return another app user's memory.

Two app users holding the same text is expected. If two of your users are in one group chat, add the chat's messages to each of them. Each copy is that app user's to search and to erase.

The id ruleCopy Anchor Link

An app user id may use letters, digits, ., _ and -, and must begin with a letter or a digit.

An app user id of up to 35 characters always fits. An id that is too long is refused with 400, and the message states the maximum length.

If your ids are longer, such as email addresses or long UUIDs with prefixes, map them to a shorter stable id, for example a hash, and keep the mapping on your side.

A header that does not fit the rule is refused with 400:

{ "detail": "X-Alexein-User is not a usable app user id: 'a.very.long.id…' (letters, digits, '.', '_' and '-', starting with a letter or digit, at most 35 characters)" }

The first write creates the app userCopy Anchor Link

You do not create app users ahead of time. The first add for a new header value creates its memory.

search, summary, facts and versions for an app user nothing was written for answer 200, empty. Other reads of that app user answer 404:

{ "detail": "no memory for app user 'bob' yet" }

Treat this as empty memory, not as a failure. A new user of your app has no memory until your backend adds something for them. Over MCP, the read tools answer that app user with an empty result instead, so a model does not mistake a new memory for a broken connection.

Listing your app usersCopy Anchor Link

users lists every app user of the key's project, with how much each holds and when it was last written to. The console's App users page shows the same list.

Deleting a whole app userCopy Anchor Link

forget erases named items, sessions, facts or excerpts. To erase everything an app user has, call users/delete with a write key and the app user in X-Alexein-User, or delete the app user in the console: open App users, pick the app user, and on its Privacy tab choose Delete app user. Either way, everything held for the app user is erased, and anything still on its way in for them.

RelatedCopy Anchor Link

• Authentication & keys: read keys, read and write keys, and projects.
• Multi-tenant SaaS: mapping your users and workspaces to app users.
• Erasure & receipts: what a forget removes.