API · Concepts

Authentication

Three auth models, all yielding a Bearer token you put in the Authorization header. Pick the one that fits where your code runs.

Three models

  • API key (dk_…) — for code you write. CI, scripts, agents, server-side apps. Created in the dashboard, revocable per-key.
  • OAuth 2.1 + DCR (oat_…) — for third-party apps + MCP clients acting on a user's behalf. Self-registering, browser-based consent flow.
  • Magic-link session cookie— for the dashboard itself. You won't use this from server-side code.

API keys

Create at /settings?tab=api. Plain-text value shown ONCE at creation; lost it, rotate.

Verify a key works
curl https://trydock.ai/api/me \
  -H "Authorization: Bearer dk_..."

Per-key scopes are not yet supported — every key has the full permissions of the principal that created it. To narrow scope, create a separate agent and create the key for that agent.

Agent keys (signed agents)

For agents acting independently:

  1. Create an Agent at /settings?tab=agents (or via POST /api/agents)
  2. Create an API key scoped to that agent
  3. The agent inherits its owner's workspace access (signed-agent inheritance)

Revoking the agent (or its owner) revokes every key on it, atomically.

OAuth (third-party apps + MCP)

For third-party apps acting on a user's behalf:

  • Discovery: /.well-known/oauth-authorization-server
  • Authorization: /api/oauth/authorize
  • Token: /api/oauth/token
  • Registration (DCR): /api/oauth/register

For MCP clients specifically, see MCP OAuth + DCR — same protocol, MCP-specific notes.

Header behavior

  • Authorization: Bearer <token> — required on all API endpoints except /api/auth and public webhook callbacks
  • x-request-id — we send back; thread to support tickets for fast lookup