Credentials
Keys are Ed25519 pairs. The private key is bound to a single organization and is never sent to Mesa. Revoking the registered public key invalidates every token the private key signed.
Token behavior
To restrict a token to specific repositories, pass either
repos (full org/repo names) or repo_ids (canonical repository IDs, at most 250 entries). The two fields are mutually exclusive.
Private-key tokens.create(...) calls require at least one author. Each author has a nonblank name and an optional email. The authors list keeps the order you supply and holds at most 100 entries.
The token authors apply to commits Mesa creates through SDK and MesaFS operations.
Minting always happens in a trusted process (ex. your application server), from a private-key or API-key client. An access-token client cannot mint further tokens.
SDK credentials
TypeScript accepts exactly one ofapiKey, privateKey, or auth. Python accepts exactly one of api_key, private_key, or auth.
The auth object contains either a private key or an existing access token. An access-token client derives its organization from the token and forwards the token unchanged on every request. Only private-key tokens work here. API-key tokens carry no organization claim, so the constructor rejects them, though they remain valid for the CLI, REST, and MesaFS mounts.
When no explicit credential is provided, the SDKs read from the environment, checking MESA_API_KEY before MESA_PRIVATE_KEY.
CLI credentials
The CLI forwards
MESA_ACCESS_TOKEN unchanged. If MESA_API_KEY is also set, the API key takes precedence.
HTTP credentials
REST and MCP requests useAuthorization: Bearer <credential>.
API keys are deprecated but remain accepted anywhere existing integrations already use them.