> For the complete documentation index, see [llms.txt](https://docs.origintrail.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.origintrail.io/references/api.md).

# API

The node API lets an application retrieve graph evidence, contribute knowledge, and participate in sharing and publication under its own credentials. Start with a concrete workflow, then use the route reference to extend it.

Use [Feature availability](/references/availability.md) for supported baselines and the generated [Tool and route map](/references/tool-route-map.md) for discovery.

Start with [Integrate an application over HTTP](/build-with-dkg/http-application.md) for a runnable client, request bodies, result checks, and error handling.

The detailed operational contract is maintained in the DKG Node Skill template and served with live node information:

* `packages/cli/skills/dkg-node/SKILL.md`
* `GET /.well-known/skill.md` on a running daemon

Use the installed node's skill and version when integrating. Live state is substituted into a maintained template; this is not a generated OpenAPI schema. The main route families are:

<table><thead><tr><th width="273">Area</th><th>Route family</th></tr></thead><tbody><tr><td>Context graphs</td><td><code>/api/context-graph/*</code></td></tr><tr><td>Knowledge Assets and VM publish</td><td><code>/api/knowledge-assets/*</code></td></tr><tr><td>SWM substrate operations</td><td><code>/api/shared-memory/catchup</code>, <code>/api/shared-memory/host-mode/*</code>, <code>/api/shared-memory/verify-batch</code></td></tr><tr><td>Query</td><td><code>/api/query</code></td></tr><tr><td>Agents and messaging</td><td><code>/api/agents</code>, <code>/api/chat</code>, <code>/api/messages</code>, <code>/api/invoke-skill</code></td></tr><tr><td>Node identity and Core profile registration</td><td><code>/api/identity</code>, <code>/api/identity/ensure</code></td></tr><tr><td>Publishing Conviction Accounts</td><td><code>/api/pca/*</code></td></tr><tr><td>Messaging SLOs</td><td><code>/api/slo</code></td></tr><tr><td>Node status and peers</td><td><code>/api/status</code>, <code>/api/peer-info</code>, <code>/api/wallets/balances</code></td></tr></tbody></table>

## Knowledge Asset Lifecycle

Named Knowledge Assets use the lifecycle route family below. The active publishing path is create, write, finalize, share, then publish; VM publishing always operates on a named KA that has already been shared to SWM.

| Lifecycle step                  | Route                                                                                                              |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Create/open WM draft            | `POST /api/knowledge-assets`                                                                                       |
| Write RDF quads                 | `POST /api/knowledge-assets/{name}/wm/write`                                                                       |
| Import a document               | `POST /api/knowledge-assets/{name}/wm/import-file`                                                                 |
| Check import status             | `GET /api/knowledge-assets/{name}/wm/extraction-status`                                                            |
| Finalize/seal                   | `POST /api/knowledge-assets/{name}/wm/finalize`                                                                    |
| Share WM to SWM                 | `POST /api/knowledge-assets/{name}/swm/share`                                                                      |
| Enqueue async WM to SWM share   | `POST /api/knowledge-assets/{name}/swm/share-async`                                                                |
| Inspect async share jobs        | `GET /api/knowledge-assets/swm/share-jobs`, `GET /api/knowledge-assets/swm/share-jobs/{jobId}`                     |
| Cancel/recover async share jobs | `DELETE /api/knowledge-assets/swm/share-jobs/{jobId}`, `POST /api/knowledge-assets/swm/share-jobs/{jobId}/recover` |
| Publish SWM to VM               | `POST /api/knowledge-assets/{name}/vm/publish`                                                                     |
| Enqueue async VM publish        | `POST /api/knowledge-assets/{name}/vm/publish-async`                                                               |
| Seed/edit from SWM or VM        | `POST /api/knowledge-assets/{name}/wm/pull-from`                                                                   |
| Discard WM draft                | `POST /api/knowledge-assets/{name}/wm/discard`                                                                     |
| Read WM quads                   | `GET /api/knowledge-assets/{name}/wm/quads`                                                                        |
| Read lifecycle descriptor       | `GET /api/knowledge-assets/{name}`                                                                                 |

Both VM publish routes accept `options.publisherNodeIdentityIdOverride`. Use a non-negative decimal string; `0` means explicit no-attribution. Omit the option to use the publisher wallet's resolved default identity, which may also be `0`. Optional node attribution for a separate publisher wallet can be configured through `/api/operational-wallets`.

For exact request bodies, response shapes, and MCP tool names, use [Node Skill](/references/node-skill.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.origintrail.io/references/api.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.