Skip to content
ConduitConduit

Connect Datto RMM to Conduit

This walkthrough connects Datto RMM (RMM) to Conduit. You create an API key and secret in Datto RMM, then add them — together with your platform region — as an organization connection in Conduit. Once connected, any MCP client your organization uses can call Datto RMM tools through Conduit’s gateway.

Before you start

Section titled “Before you start”

You need:

  • A Conduit role that can manage connections — owner or admin on your organization.
  • A Datto RMM user to own the API credentials, and an API security level carrying the right View permissions — see Permissions the API key needs below. (Enabling API access for the account itself requires an Administrator, but the key’s own security level does not have to be one.)
  • To know which platform your Datto RMM instance runs on. Conduit uses the platform code to build the API host (<platform>-api.centrastage.net), so the wrong region makes valid keys fail. If you’re unsure, Datto’s API guide explains how to identify your platform.

Permissions the API key needs

Section titled “Permissions the API key needs”

You do not need an Administrator API key. What you need is an API security level granting a few specific View permissions — and Datto supports cloning a security level (Setup → Security Levels → Copy) to build exactly that.

When you generate the keypair (Step 1), the API security level you pick there is what governs API calls. It is set on the key and is not necessarily the user’s own login security level.

Permission matrix

Section titled “Permission matrix”

Every Conduit Datto RMM tool, the Datto API endpoint it calls, and the minimum permissions that endpoint requires. Permission paths are Datto’s own, as published in the “API permissions” section of its API guide.

Conduit tool Datto endpoint Minimum permissions Global restriction
datto_list_sites GET /v2/account/sites Setup → Global Settings: View
Sites → Sites: View		 —
datto_get_site GET /v2/site/{siteUid} Sites → Sites: View —
datto_list_devices GET /v2/account/devices Setup → Global Settings: View
Sites → Sites: View
Sites → Devices: View		 Device visibility
datto_list_devices (with siteUid) GET /v2/site/{siteUid}/devices Sites → Sites: View
Sites → Devices: View		 Device visibility
datto_find_device GET /v2/account/devices Setup → Global Settings: View
Sites → Sites: View
Sites → Devices: View		 Device visibility
datto_find_device (with siteUid) GET /v2/site/{siteUid}/devices Sites → Sites: View
Sites → Devices: View		 Device visibility
datto_get_device GET /v2/device/{deviceUid} Sites → Sites: View
Sites → Devices: View		 Device visibility
datto_get_device_audit GET /v2/audit/device/{deviceUid}
GET /v2/audit/device/{deviceUid}/software		 Sites → Sites: View
Sites → Devices: View		 Device visibility
datto_list_alerts GET /v2/account/alerts/open Setup → Global Settings: View
Global → Monitor: View		 —
datto_list_alerts (with siteUid) GET /v2/site/{siteUid}/alerts/open Sites → Sites: View
Sites → Monitor: View		 —
datto_get_alert GET /v2/alert/{alertUid} Global → Monitor: View —
datto_resolve_alert POST /v2/alert/{alertUid}/resolve Global → Monitor — Manage —
datto_run_quickjob PUT /v2/device/{deviceUid}/quickjob Sites → Sites: View
Sites → Devices — Manage
Jobs → Active Jobs — Manage
Components: View		 Device visibility
API Component Level

Note that three tools call a different endpoint with different permission requirements depending on whether you pass a siteUid — the site-scoped alert call needs Sites → Monitor, while the account-wide one needs Global → Monitor. Grant both if you want the tool to work either way.

Section titled “Recommended: read-only assistant”

Clone a security level and grant View on:

  • Setup → Global Settings
  • Sites → Sites
  • Sites → Devices
  • Global → Monitor and Sites → Monitor

then set Device visibility → Sites → Add all. That covers every read tool in the table without granting Administrator. Add the Manage permissions from the last two rows only if you want the assistant to resolve alerts or run quick jobs.

Permissions vs. Device visibility

Section titled “Permissions vs. Device visibility”

These are separate categories on a security level and you need both:

  • Permissions — the section toggles above. They grant the right to ask. Datto notes that Sites → Devices alone is not enough: viewing devices additionally requires at least View on Sites → Sites.
  • Device visibility — which sites, groups, and devices the level can see. This scopes which rows come back. Granting a user site access does not grant the Permissions toggles, which is the most common reason a key still returns nothing after “giving it access to all sites.”

How a missing permission looks

Section titled “How a missing permission looks”

Datto does not document this, but the two failure modes are consistent and worth recognizing — Conduit surfaces both as a successful tool call:

  • List endpoints (datto_list_sites, datto_list_devices) return 200 with an empty list. They look like an account with no data.
  • Single-resource endpoints (datto_get_site, datto_get_device, datto_get_device_audit) fail with 403 Access forbidden.

Seeing empty site/device lists while alert tools return real data is the signature of a security level missing Sites → Sites: View.

Step 1 — Create an API key and secret in Datto RMM

Section titled “Step 1 — Create an API key and secret in Datto RMM”
  1. Sign in to Datto RMM as a user with API access. Enabling API access for the account (Setup → Global Settings → Access Control → Enable API Access) requires the Administrator security level.
  2. Generate API credentials for your user, following Datto’s API guide. Set the API Security Level to a level carrying the permissions in the table above, and the API Component Level (only datto_run_quickjob depends on it). Expected: an API Key and an API Secret, shown at creation.
  3. Copy both values.

Step 2 — Connect Datto RMM in Conduit

Section titled “Step 2 — Connect Datto RMM in Conduit”
  1. In Conduit, go to Connections (/org/catalog). Expected: the vendor catalog.
  2. Find Datto RMM in the catalog (under RMM) and click Connect. Expected: a credential form with three fields.
  3. Fill the fields:
    • API Key (required) — from Step 1.
    • API Secret (required) — from Step 1.
    • Platform (required) — pick your Datto RMM platform region from the dropdown. This must match the instance where the key was created; Conduit validates against <platform>-api.centrastage.net, so a key from one platform will not authenticate against another.
  4. Click Connect. Expected: Conduit exchanges the key/secret for a token against your platform immediately and shows a green Connected status. A bad key or wrong platform is rejected here, not on the first tool call.

The credential is stored at the organization scope, so every technician in your org shares this Datto RMM connection. (For per-technician keys, connect at the personal scope instead — see Vendor connections.)

Verify it worked

Section titled “Verify it worked”

Connect an MCP client to Conduit — Claude Desktop, Claude Code, Cursor, or any MCP-compatible client (see Connecting an AI client) — and ask it to run a read-only Datto RMM tool, such as listing open alerts. You should get real data back, and the call appears in your audit log with the correct user, vendor (datto-rmm), and a successful status. If listing sites or devices comes back empty, check the API user’s security level — see What level does the API user need?.

Troubleshooting

Section titled “Troubleshooting”
Symptom Likely cause
Connect fails with “Invalid Datto RMM platform.” The platform value isn’t one Conduit accepts. Re-open the form and pick a platform from the dropdown — free-typed or stale values are rejected server-side.
Connect fails with “Invalid API key/secret or wrong platform region. <details>” The key/secret pair is wrong, revoked, or was created on a different platform than the one selected. Verify both values and confirm the platform matches where your account lives.
Connect fails with “Datto RMM returned HTTP <status>: <details>” Datto’s OAuth endpoint returned an unexpected error — often transient, or the platform region is unreachable. Retry, and check the platform selection.
Tool calls return 403 “no credentials for vendor” Datto RMM isn’t connected at a scope this user can resolve. Connect it at the organization scope, or confirm the user’s team has a key.
Sites/devices tools return empty lists, and datto_get_site/datto_get_device return 403 — but alerts work The API security level is missing Sites → Sites: View (and Sites → Devices: View). This is the signature of the v15.1.0 permission change. See Permissions the API key needs.
Everything worked, then started failing with no change on your side Datto RMM v15.1.0 reached your account and API keys stopped bypassing security levels. Set an API Security Level with the permissions above.
Sites/devices lists come back with fewer rows than expected Device visibility on the API security level doesn’t cover those sites. Add them (or Add all) — this is separate from the Permissions toggles.
datto_resolve_alert denied Needs Manage on Global → Monitor, not View.
datto_run_quickjob denied Needs Sites → Devices: Manage, Jobs → Active Jobs: Manage, Components: View, and an API Component Level covering the component.
Calls suddenly return 403 after heavy use Datto’s rate limit (600 reads / 100 writes per 60s, counted account-wide across all API users) returns 429, then 403 with a temporary IP block if you keep going. Wait 5 minutes.
Need to rotate the credentials Regenerate the key/secret in Datto RMM, then in Conduit open Connections → Manage → Manage keys and use Default key → Rotate credentials. The old pair stops working the moment you regenerate.
Section titled “Related”