Skip to main content
Trellis supports two authentication methods for API access:
  1. Workspace API keys for trusted server-side integrations and MCP clients.
  2. Programmatic session tokens for email/password authentication flows.

Workspace API keys

Send the workspace API key as a Bearer token in the Authorization header:

Obtain an API key

  1. Log in to the Trellis Dashboard.
  2. Open the workspace where the integration should operate.
  3. Go to Settings > Developer and open the Developer / API section.
  4. In API Keys, click Create Key.
  5. Give the key a clear name, such as “Operations MCP” or “Reporting worker”.
  6. For a server integration, select each workspace the key should access.
  7. Copy the key immediately and store it in your server-side secret manager.
API keys are only displayed once. If you lose a key, revoke it and create a new one.
Only an active Trellis workspace administrator can create, update, or revoke keys. A key is automatically bound to the current workspace. There is no workspace selector, and an external integration cannot mint keys or grant itself access to another workspace.

Key scope

Each API key has exactly one owner workspace where administrators manage it. Trellis rejects requests when the workspace in the URL is not that owner workspace. Call GET /api/v1/workspaces with the key to discover its owner workspace id and display name. Use that id in workspace-scoped API requests. To change an existing server integration key, open its Permissions action in Settings > Developer. You can update its scopes without replacing or revealing the key. Its workspace cannot be changed. The same key format works for the Public REST API and Trellis MCP Server.

Revoking a key

  1. Go to Settings > Developer and open the Developer / API section.
  2. Find the key you want to revoke.
  3. Click Revoke.
  4. Confirm the action.
Any client using the revoked key will receive 401 Unauthorized.

Programmatic session authentication

Use the auth endpoints to authenticate with email and password and receive a session token. This is useful for integrations that run under a specific Trellis user account.

Create a session

Response:
Use the accessToken as a Bearer token for subsequent requests:

Refresh a session

Access tokens expire. Use the refresh token to get a new access token without re-authenticating:
The response has the same shape as POST /auth/token. Store the new refreshToken for subsequent refreshes.

Get the authenticated profile

Response:

Auth endpoints summary

The auth endpoints authenticate existing Trellis user profiles. They do not create new users or workspace memberships. Workspace API keys (trls_...) do not have user profiles and will receive 401 from GET /auth/me.

Security best practices

  • Store keys and tokens in environment variables or a secret manager.
  • Never commit a key to source control.
  • Rotate keys periodically.
  • Create separate keys for separate systems so you can revoke one integration without disrupting others.
  • Use explicit user confirmation before any connected client creates tasks, updates records, or sends messages.
  • For programmatic sessions, store refresh tokens securely and refresh proactively before the access token expires.