OpenAPI specification

https://docketrouter.ai/openapi.json is a complete OpenAPI 3.1 document for every route under /api/v1: request and response schemas, the docketrouter request extension and response block, every header DocketRouter sets, and every status code and error type a route can return.

It is checked, not hand-maintained: an automated test fails the build if a route exists with no matching path in the spec, so the document you download cannot drift silently out of date. It is the same source used to write the pages in this API reference section, so where the two ever disagree, trust the spec and tell us the docs are wrong.

Fetching it

curl

curl -s https://docketrouter.ai/openapi.json | jq '.paths | keys'

Served as a static file, so it needs no API key and is not rate-limited.
servers is https://docketrouter.ai; every path in the document already includes the /api/v1 prefix, matching what you send on the wire.
Security schemes: ApiKeyAuth (a dr-… key as an Authorization: Bearer header) and SessionAuth (the Clerk session cookie the web dashboard uses). Routes that also accept the unauthenticated site playground list an empty security requirement alongside those two; see the route's own description for the exact rule.

Two response shapes on a 400

Most routes fail validation with the standard envelope, {"error":{"message","type",...}}. A handful of older routes (minting a key, uploading a file, the two billing-checkout routes, queuing an HLL submission, and POST /route) instead return zod's raw {"error":{"formErrors","fieldErrors"}} shape, with no message or type field. The spec documents both shapes exactly where each applies (see the ZodFlattenError schema) rather than smoothing over the inconsistency. See Errors, retries and limits for the full table.

Generating a TypeScript client

openapi-typescript turns the spec into types only; you still call fetch yourself, which keeps the bundle small.

generate types

npx openapi-typescript https://docketrouter.ai/openapi.json -o docketrouter.d.ts
# then: fetch("https://docketrouter.ai/api/v1/chat/completions", { ... }) typed against
# paths["/api/v1/chat/completions"]["post"]

Generating a Python client

openapi-python-client scaffolds a full package with request models and a typed client class.

generate a package

pip install openapi-python-client
openapi-python-client generate --url https://docketrouter.ai/openapi.json
# creates ./docketrouter-api-client/, importable as a normal package

Using it with an AI agent

Most agent frameworks and tool-calling runtimes can turn an OpenAPI document directly into tool definitions: each operationId in the spec (e.g. createChatCompletion, ragQuery, checkCitations) becomes one callable tool, with its parameters and request body taken from the schema and its description taken verbatim from this document. That means an agent can call DocketRouter's grounded chat completion, run a bare retrieval query, or verify a citation, without any hand-written tool schema to keep in sync -- point the framework's OpenAPI tool loader at https://docketrouter.ai/openapi.json, supply the bearer key as the auth credential it asks for, and the agent has the same surface a human integrator does. Keep the model on the callable allowlist (callable_models in GET /models) and mind the per-identity rate limits in Errors, retries and limits if the agent retries aggressively.

Something here wrong or missing? Mail hello@docketrouter.ai with the request_id and we will fix the docs or the API, whichever is broken.