API & MCP
Purpose
Every capability of this system is reachable over the interface — not as an add-on but as a building principle. The user interface is a client of the API, not a privilege. There is no function that exists "only in the UI".
The practical benefit: whatever you do by hand today can be done tomorrow by a program, an automation or an AI — without anybody having to rebuild it.
Scope
- REST API under
/api/v1with an automatically generated OpenAPI description. Errors follow one
uniform format instead of differing per endpoint.
- The public identifier is the ULID — a sortable identifier that does not reveal how many records
exist and cannot practically be guessed.
- Permissions apply unchanged. The same checks as in the interface take effect over the API,
object by object. There is no route that bypasses the check.
- MCP connection: the operations are exported from the OpenAPI description as AI tools. An AI
therefore works through the same endpoints as any other client — with the same permissions and the same logging.
- Access via tokens that exercise their user's permissions and can be revoked at any time.
Interplay
The API is the shared foundation the other areas build on: the automation engine calls the same operations, the AI platform reaches them through MCP, and integrations connect foreign systems. Every one of these uses leaves its trail in traceability — distinguishing whether a human, an AI or an automation acted.
Limits
- No way around permissions. A token can never do more than the user it hangs on. Wanting to see
more over the API means needing more permissions, not a different route.
- Some bootstrap routes deliberately do not appear in the MCP catalogue — sign-in, public forms,
webhook receivers. Their administrative counterpart exists as a regular operation in each case.
- The API is versioned. A change to the wire format is an announced cut, not a side effect of an
update.