API Overview - drio Docs

Understand what the supported drio management API covers and how the v3 intent-level model works.

The drio API is a management API. It lets engineering teams automate the same workflow they would otherwise perform in the dashboard: inspect apps, turn discovered integration operations into runtime-backed tools, validate drafts, and publish releases.

This latest docs set describes v3, which is the supported control-plane API.

If you need an older contract for migration or historical reference, use the archived v2 docs or archived v1 docs.

Who This Page Is For

developers integrating drio into internal workflows
technical reviewers evaluating the external API surface
teams that want to automate app creation and release workflows

If you are primarily building in the UI, you can usually skip this section and continue with the product-facing docs instead.

What The API Is For

Use the API to:

inspect app, draft, and release state
inspect integrations and discovered operations
import integration operations as runtime-backed MCP tools
create operation-backed tools without managing internal binding rows
validate whether a draft is publishable
preview the draft runtime config
publish releases from your own tooling

What The API Is Not For

The management API is separate from the deployed MCP endpoint used by end users inside ChatGPT, Claude, Cursor, or other AI clients.

Use:

the management API for app lifecycle automation
the MCP endpoint for runtime usage by AI clients

See Connect to AI clients for the runtime side.

The Core Model

The supported API is built around five concepts:

app: the stable container and top-level metadata
draft: the current mutable working state for that app
release: an immutable published snapshot
integration: an upstream system connected to the app
operation-backed tool: an MCP tool derived from an integration operation

Normal writes update the app's current draft. Publishing validates the draft, creates a release, and rotates the app to a fresh successor draft.

v3 is intentionally intent-level. It does not expose low-level storage writes for tool bindings, chains, widgets, or internal execution nodes. When you create a tool from an operation, drio derives the required runtime records.

Main Workflow

Today, the API is centered around this flow:

discover auth
authenticate
list apps
inspect compact authoring state
list integrations and operations
import or create operation-backed tools
validate and preview the draft
publish a release

If you want the shortest working example, start with API quickstart.

Base Routes

resource API: /api/v3
OpenAPI document: /api/v3/openapi.json
OAuth discovery:
- /.well-known/oauth-authorization-server
/.well-known/oauth-protected-resource

What The API Supports Today

Use these with a bearer access token.

GET /api/v3/me
GET /api/v3/apps
GET /api/v3/apps/{app_id}
GET /api/v3/apps/{app_id}/authoring-state
GET /api/v3/apps/{app_id}/integrations
GET /api/v3/apps/{app_id}/integrations/{integration_id}/operations
GET|POST /api/v3/apps/{app_id}/tools
POST /api/v3/apps/{app_id}/integrations/{integration_id}/operations/import-tools
POST /api/v3/apps/{app_id}/draft/validate
GET /api/v3/apps/{app_id}/draft/runtime-preview
POST /api/v3/apps/{app_id}/releases

The old /api/v2 routes return 410 Gone.

Auth Model

drio publishes the discovery entrypoints for the management API, but the OAuth authorization server is AuthKit.

In practice the boundary is:

start at drio discovery
register the client with AuthKit
authorize and exchange tokens with AuthKit
call drio's protected routes with the returned bearer token

OAuth-aware clients can usually discover the required endpoints automatically from /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource.

Typical Flow

Mermaid diagram source:

sequenceDiagram
  autonumber
  participant Client as API client
  participant Drio as drio API
  participant AuthKit as AuthKit

  Client->>Drio: Discover /.well-known metadata
  Client->>AuthKit: Register client via DCR
  Client->>AuthKit: Authorize with PKCE
  AuthKit-->>Client: Redirect back with authorization code
  Client->>AuthKit: Exchange code for tokens
  AuthKit-->>Client: access_token + refresh_token
  Client->>Drio: Call /api/v3/apps with Bearer token
  Drio-->>Client: Protected API response

What The Client Needs To Keep Stable

For the authorization code flow to work cleanly:

discover the authorization server from drio first
keep the returned client_id
send the same registered redirect_uri during authorize and token exchange
keep PKCE enabled for authorization code flow