# Resources (/docs/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.

| Resource               | URL                                                                           | Use it for                                                          |
| ---------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| TypeScript SDK         | [`@doctronic-ai/sdk`](https://www.npmjs.com/package/@doctronic-ai/sdk) on npm | Calling the API from Node; see [SDKs](/docs/sdks/)                  |
| Python SDK             | [`doctronic`](https://pypi.org/project/doctronic/) on PyPI                    | Calling the API from Python, sync or async; see [SDKs](/docs/sdks/) |
| OpenAPI 3.1 contract   | [`/openapi/doctronic-v1.json`](/openapi/doctronic-v1.json)                    | Operations, parameters, schemas, responses, and server URLs         |
| Documentation index    | [`/llms.txt`](/llms.txt)                                                      | Discovering pages and their Markdown URLs                           |
| Complete documentation | [`/llms-full.txt`](/llms-full.txt)                                            | Loading every page as one text file                                 |
| Page Markdown          | `/llms.mdx/docs/{page}/content.md`                                            | Loading one page without site navigation                            |

For example, this page is available as Markdown at
[`/llms.mdx/docs/resources/content.md`](/llms.mdx/docs/resources/content.md).

Before you generate a client from the contract, try the official [SDKs](/docs/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 [#download-the-contract]

```bash
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](/docs/sdks/#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](/docs/changelog/) summarizes each contract change.

## Choose the right source [#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](/docs/conversations/streaming/#event-reference) define the event names and
payloads your integration should recognize.

## Control automated callers [#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](/docs/authentication/#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](/docs/safety/).
* Use idempotency keys on supported mutations, and reconcile other operations before replaying them.
  See [errors](/docs/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 [#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](/docs/authentication/#get-access)), or to
[business@doctronic.ai](mailto:business@doctronic.ai?subject=Developer%20API%20support) 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 [#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.