API reference
Generated from the capability registry. Not written by hand, and therefore unable to drift.
The reference below is generated from the capability registry — never written by hand. Each page carries the contract version and the commit it came from.
Generated, not written
Every reference page is generated at build time from the capability registry itself — the same declaration the server reads to decide what exists, who may call it, and what parameters it takes. Nobody edits these pages. A capability that is removed disappears from this reference on the next build, and a build whose generated reference differs from the committed one fails.
That is not tidiness. A reference maintained by hand drifts, and a drifted reference is worse than no reference: it is a documented promise the server does not keep.
What appears, and what never does
Only capabilities that are read, or the propose half of a proposal pair, and only those addressed
to tenants. A write capability is not listed anywhere, because it is not directly callable — it is
reached through the proposal it belongs to, and listing it would invite a client to try.
The contract itself
The OpenAPI document these pages are generated from is served as-is at
/openapi.json. It is the same file the server publishes — not a copy kept in step
by hand — so it carries the version and commit shown at the bottom of every reference page.
Point a client generator at it, load it into Postman or Insomnia, or diff it between releases to see exactly what changed:
curl -O https://developers.digitalyser.io/openapi.jsonEverything the document declares is served, and everything served is declared: response bodies are generated from the capability payloads intersected with the surface allowlist, so a field that appears here is a field the API returns.
Use it in your tools
Postman, Insomnia, Bruno and Hoppscotch all import OpenAPI 3 directly — paste the URL above, or the downloaded file. The import already carries what you would otherwise configure by hand:
| from the document | what your client gets |
|---|---|
servers | the base URL, https://app.digitalyser.io/api |
securitySchemes.agent-token | bearer auth, pre-wired on every operation |
security at the root | every operation marked as requiring it |
Only one thing is yours to add: the token value itself. Put your dga_… token in the collection or
environment variable your tool created for the bearer scheme, never in a request URL — see
credentials for how to obtain one.
Client generators read the same file: openapi-generator, oapi-codegen, openapi-typescript and
their equivalents all take the URL directly.
We do not ship a Postman collection, and that is deliberate. A collection is a second copy of the contract — it would have to be regenerated on every API change, and the day someone forgot, it would describe an API that no longer exists. The document above is the one the server publishes; importing it is always current, and it works in every tool rather than one.
Errors
Every refusal this API can return has its own entry in the error reference,
and the type of a refusal points straight at it. That URI is stable — it is part of the contract,
and safe to branch on.
Capabilities restricted to a plan are listed and marked as such. Gating happens when a connection is authorised, not when you read a page: you should be able to see what you would get before you buy it.
Generated from the capability registry — API version 1, 18 paths, from 4815355 (2026-10-12).