Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.myme.so/llms.txt

Use this file to discover all available pages before exploring further.

AUTH_MODE selects how the server authenticates callers. Two values:
  • keys (default) — every tenant exists because someone created its admin key. Tenant provisioning is a manual server-side operation; there is no public signup flow. Suitable for self-hosted single-tenant setups, internal multi-tenant deployments where admins provision tenants out-of-band, and development.
  • hosted — a managed-service shape. /auth/signup is public, creates a user + tenant + admin key atomically, and returns the plaintext key in the response. Suitable for cloud deployments intended to serve end-users without operator involvement per signup.
API keys work the same way in both modes. The difference is whether a public endpoint provisions them.

​
Enabling hosted mode

export AUTH_MODE=hosted
At boot, the server mounts three additional routes under /auth:
  • POST /auth/signup — creates a user record, a tenant, and an admin API key. No auth required.
  • GET /auth/me — returns the authenticated key’s user and tenant. Requires a valid bearer token.
  • Refresh / key rotation — hosted mode also exposes key-rotation helpers for the authenticated user.
Hosted mode requires a storage backend that supports the users and tenants stores — both Postgres and SQLite do. The server refuses to start in hosted mode without them.

​
Signup payload

POST /auth/signup
{
  "email": "user@example.com",
  "name": "Optional display name",
  "provider": "google",
  "provider_account_id": "<stable-id-from-provider>"
}
The provider + provider_account_id pair identifies the user across logins — typically sourced from an upstream identity provider (Google, GitHub, WorkOS, etc.). Signing in through the same provider identity a second time returns the existing tenant and a freshly-rotated admin key; there is no “login” in the traditional session sense, only key provisioning. The response shape returns the user, tenant, and an admin API key for the new tenant.

​
Tenant model

One tenant per signup. A single user always owns exactly one tenant in hosted mode; users who want separate personal and work spaces sign up twice with different provider identities. Cross-tenant sharing is an explicit grant per scope, the same as in keys mode. See Spaces.

​
Managing keys in hosted mode

The admin key returned at signup is the user’s primary credential. Apps that need scoped access create further keys under the same tenant via the normal POST /keys endpoint using the admin key, or via OAuth’s authorization-code flow if the deployment also registers OAuth clients. Rotating the admin key is the user’s responsibility; the SDK’s client.keys.* surface is available to the user directly.

​
Operating a hosted deployment

Beyond AUTH_MODE=hosted, the additional operational requirements are:
  • TLS everywhere. Signup posts credentials; HTTPS is non-optional. Set ENABLE_HSTS=true behind a TLS terminator.
  • Durable Postgres. SQLite is viable but multi-user contention quickly argues for Postgres. Configure STORAGE_DIALECT=pg and DATABASE_URL.
  • Rate limits on /auth/token and /keys are tight. Signup traffic doesn’t hit /auth/token, but tightening /auth/signup at the reverse proxy guards against enumeration.
  • Blob storage reachable from every instance. Hosted deployments usually run behind a load balancer; use BLOB_BACKEND=s3 rather than filesystem to avoid per-host divergence.
See Configuration for the full variable set.