Draftlink

Documentation map

The docs portal stays in the same application as the product shell so setup, deployment, connector, and developer guidance can evolve with the codebase.

In-repo docs7 foundation routes5 developer routesCurrent: API Reference

Foundation docs

OverviewRoute
Start with the current architecture, product surfaces, and the stable documentation sections.
Getting StartedRoute
Install the workspace, configure local env files, and run the first verification flow.
DeploymentRoute
Use the managed bridge deployment order, health checks, migrations, and workspace bootstrap flow.
ConnectorsRoute
Understand the Figma reference connector, Satellite runtime, and explicit session routing model.
SecurityRoute
Review auth lanes, workspace isolation, policy controls, rate limiting, and audit semantics.
API ReferenceOpen
Browse the stable HTTP route groups, shared envelopes, auth lanes, and machine-readable errors.
TroubleshootingRoute
Use the current operational failure patterns for readiness, auth, session liveness, policy, and MCP issues.

Developer docs

DevelopersRoute
Developer-facing entry point for HTTP, MCP, connector, and shared-contract guidance.
Developer QuickstartRoute
Bring up the bridge, connect one runtime, and make the first explicit authenticated calls.
HTTP GuideRoute
Use the bridge HTTP transport with the correct auth lane, shared envelopes, and explicit targetSessionId routing.
MCP GuideRoute
Use the Streamable HTTP MCP endpoint, LIST_CAPABILITIES, and the same connector-neutral tool catalog.
Connector ModelRoute
Understand connector definitions, capability metadata, data scopes, and high-risk policy presets.

Auth lanes

Different actors use different lanes on purpose. The transport does not collapse human bootstrap, workspace discovery, and automation execution into one bearer mode.

Health and readiness

No bearer token required

Use these routes for process liveness and dependency readiness before any authenticated discovery or execution call.

GET /healthz
GET /readyz

Human account bootstrap

Supabase user bearer token

This route resolves bridge-owned workspace memberships for a signed-in human user and is the secure shell bootstrap path.

GET /api/v1/account/session

Workspace discovery and governance

API key or Supabase bearer token plus x-uab-workspace-id

Workspace-scoped product routes can use either automation auth or human auth, but both lanes require explicit workspace targeting.

GET /api/v1/capabilities
GET /api/v1/connectors
GET /api/v1/sessions
GET /api/v1/sessions/:sessionId
GET /api/v1/audit
GET /api/v1/admin/api-keys

Automation and execution

API key

Agent and integration execution stays on the API-key lane so transport adapters can remain thin over the shared controller.

GET /api/v1/tools
POST /api/v1/tools/execute
POST /mcp

Shared envelopes

HTTP routes keep one ok-or-error envelope shape so product routes, typed clients, and operators can interpret failures consistently.

Success envelope

JSON

{
  "ok": true,
  "connectorType": "figma",
  "capabilities": [
    {
      "capabilityId": "SET_OPACITY",
      "kind": "tool",
      "connectorType": "figma",
      "commandType": "SET_OPACITY",
      "description": "Set the opacity on one selected node.",
      "outputDataScopes": ["NODE_METADATA"]
    }
  ]
}

Error envelope

JSON

{
  "ok": false,
  "error": {
    "code": "UNAUTHORIZED",
    "message": "Authenticated workspace does not match the requested workspace."
  }
}

HTTP route groups

These route groups reflect the current bridge-server transport registrations, including the newer admin and audit paths used by the secure shell.

Health and account

Start here for deployment probes and human workspace bootstrap.

GET

/healthz

Auth: none

Purpose: Proves the bridge process is alive.

GET

/readyz

Auth: none

Purpose: Proves Postgres and Redis are reachable through the active bridge service.

GET

/api/v1/account/session

Auth: Supabase bearer token

Purpose: Returns the authenticated human session plus bridge-owned workspace memberships.