Skip to main content
The hosted backend is https://convex.memorycrystal.ai on Convex Cloud. Protected memory, knowledge-base, research, and asset routes require an appropriate Bearer API key. Create keys in the dashboard. A newly created key is shown once and stored as a hash. The default active-key cap is 150 per account; revoke unused keys before creating replacements.
The key identifies the account owner. A request-body userId cannot select another account. Resource and scope checks still apply; hidden resources can return 404 just like missing ones. Agent and channel scope partition data within an account; use separate accounts and keys for separate security boundaries. A server process’s environment key does not replace the inbound Bearer credential required by a protected hosted request.

​
Device sign-in

CLI installers can use POST /api/device/start and GET /api/device/status for browser-approved device sign-in. These routes have their own device-code contract rather than the ordinary memory Bearer flow. There is no public HTTP issueApiKeyForUser endpoint. Use the dashboard or the supported device flow.

​
Errors and rate limits

Invalid, inactive, or expired keys return 401 on protected routes. Authentication bookkeeping varies by route: the main memory handler awaits its last-use update; KB and export paths schedule that bookkeeping without waiting. The shared limiter returns HTTP 429 with:
Its headers include Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Scope. Do not require these on every success response or expect X-RateLimit-Reset. Turn capture, export, and device routes have response differences; see rate limits. See memory endpoints, KB endpoints, and MCP setup.

​
Set up and verify access

  1. Sign in to the dashboard and create an API key.
  2. Copy the key when shown; the service stores its hash rather than a recoverable plaintext copy.
  3. Store the key in your client’s secret configuration. For shell examples, expose it as MEMORY_CRYSTAL_API_KEY without putting it into source control.
  4. Send the health request above. A successful authenticated response confirms that this key reaches the service.
  5. Configure your MCP client using the MCP integration instructions. Hosted MCP still requires the caller’s Bearer credential.
A successful health response includes:
This is a response excerpt; health also returns checks and build information. It does not test every provider.

​
Rotate and troubleshoot

Create a replacement key, update the intended clients, and verify them before revoking the old key. Revoked keys cannot authenticate new requests. If you reach the active-key cap, remove unused keys before adding another. Do not send the raw key in support messages or paste an Authorization header into a public report. See errors for endpoint-specific responses.