Resources

Call the API through the official SDKs, load the API definition and these docs into coding assistants and contract validators, and get help when something goes wrong.

For example, this page is available as Markdown at /llms.mdx/docs/resources/content.md.

Before you generate a client from the contract, try the official SDKs. They're generated from the same contract, and they add what a generated client leaves to you: user scope, idempotency keys and safe retries, typed stream events, and webhook verification.

Download the contract

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

To pick up a contract change in an official SDK, upgrade the package rather than regenerating anything; see versioning. Validate the file before using it to update your own generated client, schema validator, or tool definition, and review the diff before you deploy. The changelog summarizes each contract change.

Choose the right source

Use the OpenAPI contract for HTTP operations and JSON shapes. Use the Markdown docs for workflow guidance, stream handling, and launch requirements.

OpenAPI represents the stream as text/event-stream. Its published event examples and the event reference define the event names and payloads your integration should recognize.

Control automated callers

These files describe the API. Access comes from credentials: runtime calls need an API token and, for user-scoped operations, the right X-Doctronic-User-ID. Keep the token out of model prompts, generated output, traces, and documentation corpora; see keep the token on your backend.

To expose Doctronic operations to an agent or tool-calling model, give the model a narrow tool on your backend instead of the token. That tool should:

• Allow only the operations its workflow needs.
• Resolve the patient and their user ID on your backend, never from model input.
• Validate input against the OpenAPI contract before sending it.
• Handle guardian and skill_code.cta events in product code; see safety.
• Use idempotency keys on supported mutations, and reconcile other operations before replaying them. See errors.
• Return only the fields the calling workflow needs, and log operation and outcome metadata without unrestricted patient content.
• Fall back to a human-visible path for errors and unknown events.

Report an API problem

Keep these details with every request record, so a report is ready when you need one:

• The X-Request-ID response header.
• For a stream request: the chat ID, user ID, event names received, UTC timestamps, and whether the HTTP stream closed normally.

Keep the API token and unrestricted patient content out of these records.

To report a problem, send these details to your Doctronic contact (see get access), or to business@doctronic.ai if you don't have one:

• The environment: staging or production.
• The SDK and its version, if you use one. The SDKs send them as the User-Agent, doctronic-typescript/<version> or doctronic-python/<version>.
• The HTTP method and path.
• The UTC time and X-Request-ID.
• The response status and error code.
• Whether a retry reused the same Idempotency-Key.
• The last safe workflow state.

Limits

• Doctronic doesn't publish an MCP server.
• The API has no delegated agent authorization. An automated caller can't select an arbitrary X-Doctronic-User-ID or expand its own permissions.
• The API's authorization and safety boundaries apply the same way to automated callers.