Docs for coding tools

Load the OpenAPI contract or plain-text documentation into coding and validation tools.

Use these files when a coding assistant, client generator, or contract validator needs the public API definition without the rendered site navigation.

Resource	URL	Best use
OpenAPI 3.1	`/openapi/doctronic-v1.json`	Operations, parameters, schemas, responses, and server URLs
Documentation index	`/llms.txt`	Discover documentation pages and their Markdown URLs
Complete documentation	`/llms-full.txt`	Load the public documentation as one text resource
Page Markdown	`/llms.mdx/docs/{page}/content.md`	Load one documentation page without site navigation

For example, the Markdown version of this page is available at /llms.mdx/docs/agent-resources/content.md.

Choose the right source

Use OpenAPI as the contract for HTTP operations and JSON shapes. Use the Markdown documentation for workflow guidance, SSE compatibility rules, and production considerations.

The SSE stream is represented as text/event-stream in OpenAPI. Its published event examples and the streaming guide define the event names and payloads that an integration should recognize.

Download the contract

curl --fail --location \
  "https://docs.doctronic.ai/openapi/doctronic-v1.json" \
  --output doctronic-openapi.json

Validate the downloaded file before using it to update a generated client, schema validator, or tool definition. Review contract changes before deployment rather than updating production behavior automatically.

Keep runtime credentials separate

These resources describe the API but do not grant API access. Runtime calls still require a Bearer token provisioned manually by Doctronic and, for user-scoped operations, the correct X-Doctronic-User-ID.

Keep the token in an organization-controlled backend. Do not place it in a model prompt, browser session, client application, generated artifact, trace, or documentation corpus.

Control automated callers

If an automated system can initiate API calls:

Allow only the operations required for its workflow.
Resolve the user identity in trusted backend code.
Validate requests against OpenAPI before sending them.
Define product-controlled handling for any emitted guardian and skill_code.cta events.
Use documented idempotency keys for supported mutations and reconcile unsupported operations before replaying them.
Record operation and outcome metadata without copying unrestricted patient content.
Keep a human-visible fallback for errors and unknown events.

The documentation formats do not change the clinical API's authorization or safety boundaries.

MCP and tool calling

Doctronic does not currently publish a public MCP server. If your application exposes Doctronic operations to an agent or tool-calling model, put a narrow tool in your backend instead of giving the model an organization token. The backend should resolve the patient, enforce an operation allowlist, validate input against OpenAPI, and return only the fields required by the calling workflow.

The public API does not provide delegated agent authorization. A caller must not select an arbitrary X-Doctronic-User-ID or expand its own permissions.