Integrations
One registry, several shapes. What each platform needs, and what it cannot do.
The same registry reaches every platform, but each one demands a different shape. This page says plainly which path works for you and what it costs.
| Platform | Path | Credential | Status |
|---|---|---|---|
| Claude — Desktop, Code, claude.ai | MCP | OAuth dga_ | Available |
| Cursor, VS Code, LangGraph | MCP | OAuth dga_ | Available |
| n8n | REST /v1 | Derived project token dga_ | In progress |
| Make, Zapier | REST /v1 | Derived project token dga_ | Planned |
| ChatGPT | MCP | OAuth 2.1 | Planned |
Automation platforms use a derived project token, not a scoped API key — an API key opens no capability, because a capability takes its project from the credential and a key carries none. An administrator derives one token per project, without any browser step. See credentials.
Why n8n goes through REST
n8n's MCP Client Tool node connects to an SSE endpoint. Digitalyser.io serves Streamable HTTP only, and will not reinstate SSE: the July 2026 protocol revision removed SSE resumption, and under SSE the URL parameter never propagates to the POST — which would silently break the one-project-per- connection guarantee that the whole authorisation model rests on.
So n8n talks to the REST facade with an HTTP Request node and a scoped key. That is not a workaround; it is why the facade exists.
Choosing between MCP and REST
Use MCP when a human is in the loop through an assistant: the agent reads the catalogue, asks what it needs, and brings proposals back for confirmation.
Use REST when a system acts on a schedule with no one watching: it knows what it wants, it wants a status code, and it wants the same answer every time.
Both enforce the same permissions. They differ in one visible way — see
conventions — because MCP wraps every error in a 200 JSON-RPC envelope while
REST returns real HTTP status codes. Same cause, two shapes.