Authentication
Memanto uses a server-side Moorcheh API key combined with per-agent session tokens to scope memory operations, plus a separate management credential that gates agent lifecycle endpoints (create/list/get/delete/activate/deactivate an agent, and the status endpoint).Server (Moorcheh)
Memanto reads
MOORCHEH_API_KEY from its environment / configuration and authenticates on the server when calling Moorcheh.Memory Operations (Client)
Memory endpoints require a session token in the
X-Session-Token header. Tokens are obtained by activating an agent.Server-Side Moorcheh API Key
Memanto does not accept a Moorcheh API key from clients. The key is set once on the server and is used for every Moorcheh call Memanto makes:MOORCHEH_API_KEY is not configured or MOORCHEH_API_KEY is invalid.
Getting a Moorcheh API Key
- Go to https://console.moorcheh.ai/api-keys
- Create a new API key
- Configure it on the Memanto server (env var, secrets manager, etc.)
Session Token Authentication
When Session Tokens Are Required
Memory operations require anX-Session-Token header obtained from agent activation:
POST /api/v2/agents/{agent_id}/rememberPOST /api/v2/agents/{agent_id}/batch-rememberPATCH /api/v2/agents/{agent_id}/memories/{memory_id}POST /api/v2/agents/{agent_id}/remember/extractPOST /api/v2/agents/{agent_id}/upload-fileDELETE /api/v2/agents/{agent_id}/memories/{memory_id}POST /api/v2/agents/{agent_id}/recallPOST /api/v2/agents/{agent_id}/recall/as-ofPOST /api/v2/agents/{agent_id}/recall/changed-sincePOST /api/v2/agents/{agent_id}/recall/recentPOST /api/v2/agents/{agent_id}/answerPOST /api/v2/agents/{agent_id}/daily-summaryPOST /api/v2/agents/{agent_id}/conflicts/generateGET /api/v2/agents/{agent_id}/conflictsPOST /api/v2/agents/{agent_id}/conflicts/resolvePOST /api/v2/agents/{agent_id}/deactivate
agent_id in the path; otherwise the request is rejected.
Cookie-Based Authentication (Browser / Web UI Clients)
As an alternative to theX-Session-Token header, Activate Agent also sets an HttpOnly, SameSite=Strict cookie named memanto_session_token. get_current_session accepts either the header or the cookie — browser clients (like the built-in Web UI) never need to read the token out of JavaScript.
- The cookie is set on
POST /api/v2/agents/{agent_id}/activateand cleared onPOST /api/v2/agents/{agent_id}/deactivate. - The cookie’s
Secureattribute is set dynamically from the actual request scheme (Securewhen the request arrived over HTTPS, omitted over plain HTTP). Memanto binds0.0.0.0with no built-in TLS by default, so a hardcodedSecureflag would silently stop browsers from ever sending the cookie back in that default deployment — put Memanto behind an HTTPS-terminating proxy in production to getSecurecookies. - If a near-expiry session is auto-renewed mid-request, the server transparently re-sets the cookie with the new token so cookie-authenticated clients don’t go stale.
- API clients that use the
X-Session-Tokenheader (CLI, SDKs, direct API integrations) are unaffected — the cookie is purely additive for browser-based callers.
Management Endpoint Authentication (Agent Lifecycle)
Agent-lifecycle endpoints don’t take a session token (there’s no session yet), but as ofv0.2.7 they do require authorization — either a management credential or a loopback client:
POST /api/v2/agents— Create agentGET /api/v2/agents— List agentsGET /api/v2/agents/{agent_id}— Get agent detailsDELETE /api/v2/agents/{agent_id}— Delete agentPOST /api/v2/agents/{agent_id}/activate— Activate (returns the token)POST /api/v2/agents/{agent_id}/deactivate— Deactivate (also checked here, in addition to the session token above)GET /api/v2/status— Inspect the active session
- The caller presents the management credential, matched with a constant-time comparison against the configured server credential:
orThe expected credential is
MOORCHEH_API_KEYon the cloud backend, orMEMANTO_SECRET_KEYon the on-prem backend (see Session cookie hardening for how that same secret is generated when unset). - The request originates from the loopback interface (
127.0.0.1/::1, including IPv4-mapped IPv6) — so the local desktop CLI and Web UI keep working without attaching a key on every call.
401 - Unauthorized (Management Auth Required)
GET /health,GET /ready,GET /live— Health & Readiness probes
Getting a Session Token
- Activate an agent (from
localhost, no management credential needed):
- Response contains a session token:
- Use the token in subsequent requests:
Example Request with Session Token
In Python
Session Token Details
Token Format
Session tokens are JWT (JSON Web Tokens):Token Expiration
- Duration: configured by the server via
SESSION_DEFAULT_DURATION_HOURS(typically 6 hours). - Auto-renewal: Memanto auto-renews sessions that are near expiry on the next memory request.
- Renewal: activate a new session with
POST /api/v2/agents/{agent_id}/activate.
Decode Token (Python)
Common Errors
Missing Session Token
X-Session-Token.
Invalid Session Token
Session Expired
POST /api/v2/agents/{agent_id}/activate.
Management Auth Required
Authorization: Bearer <key> or X-Api-Key: <key> (the cloud MOORCHEH_API_KEY or the on-prem MEMANTO_SECRET_KEY), or call from a loopback client. See Management Endpoint Authentication.
Session / Agent Mismatch
If the session token was issued for a different agent than the one in the URL path, the server returns500 with:
agent_id.
Best Practices
DO
- Store
MOORCHEH_API_KEYas a server-side secret (env var, Secrets Manager, etc.) - Keep session tokens in memory on the client (don’t persist long-term)
- Rotate the Moorcheh key periodically
- Treat session tokens as sensitive — they grant memory access for an agent
- If Memanto is reachable from outside
localhost, attachAuthorization: Bearer <key>orX-Api-Keyon agent-lifecycle calls — don’t rely on network placement alone
DON’T
- Commit
MOORCHEH_API_KEYto source control - Reuse a session token across different agents
- Log session tokens (or the management credential) to files or telemetry
- Bind Memanto to
0.0.0.0on an untrusted network without also setting a realMOORCHEH_API_KEY/MEMANTO_SECRET_KEY— that credential is what gates agent-lifecycle access for non-loopback callers
Security
API Key Management
Development:Session Token Security
- Tokens are JWT — treat as sensitive
- Don’t log tokens
- Don’t expose in client-side code that ships to end users
- Short-lived (configurable, default ~6 hours)
- Unique per activation
Next Steps
- Activate Agent to obtain a session token
- Get Current Session to inspect the active session
- Remember to start storing memories