Connect Atera to Conduit

This walkthrough connects Atera (RMM/PSA) to Conduit. You create an API key in Atera, then add it as an organization connection in Conduit. Once connected, any MCP client your organization uses can call Atera tools through Conduit’s gateway.

Menu labels can change

The Atera-portal steps below reflect Atera’s API-key flow at time of writing; menu labels can shift between Atera releases. If a label differs, look for the nearest equivalent in the same area of the portal.

Before you start

You need:

• A Conduit role that can manage connections — owner or admin on your organization.
• An Atera account with the Admin role. The API key inherits the permissions of the user who creates it, so that user’s role needs to cover whatever you want the AI to do (read tickets, create tickets, run agent actions, etc.).

Step 1 — Create an API key in Atera

1. Sign in to Atera as a user with the Admin role. Expected: the Atera dashboard.
2. Open Admin → API. Expected: the API settings page.
3. Click Generate API Key. Expected: a new key is created and shown once.
4. Copy the key immediately. Atera shows the full key value only at creation — if you lose it, you’ll need to regenerate, which invalidates the old key.

Caution

Copy the key now and store it somewhere safe. Don’t paste it into chat, email, or a shared document — the next step moves it directly into Conduit, which encrypts it at rest. If you accidentally expose the key, regenerate it in Atera first (Admin → API → Regenerate); the exposed key becomes useless immediately.

Step 2 — Connect Atera in Conduit

1. In Conduit, go to Connections (/org/catalog). Expected: the vendor catalog.
2. Find Atera in the catalog (under RMM) and click Connect. Expected: a credential form with a single API Key field.
3. Paste the Atera API key from Step 1 into the API Key field.
4. Click Connect. Expected: Conduit validates the key against Atera immediately and shows a green Connected status. A bad key 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 Atera connection. (For per-technician keys, connect at the personal scope instead — see Vendor connections.)

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 Atera tool, such as listing active alerts or recent tickets. You should get real data back, and the call appears in your audit log with the correct user, vendor (atera), and a successful status.

Troubleshooting

Symptom	Likely cause
Connect fails immediately in Conduit (“Invalid Atera API key”)	The key was regenerated in Atera after Conduit stored it, was copied incompletely, or the user that created it was disabled/deleted (the key dies with the user). Generate a fresh key under an active Admin user and re-connect.
Tool calls return 403 “no credentials for vendor”	Atera 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.
Tool calls succeed but specific actions are denied	Atera API keys inherit the creating user’s role permissions — read-only actions need read access, write actions (create/update tickets, run agent actions) need the matching write permission. Adjust the Atera user’s role, then regenerate the key.
Vendor health shows yellow/degraded	Conduit’s health check sees Atera responding slowly. Usually a transient Atera-side load spike — recovers automatically.
Need to rotate the key	Regenerate in Atera (Admin → API → Regenerate), then update the credential at /org/catalog. The old key stops working the moment you regenerate.

Related

• Vendor connections — credential scopes, rotation, and the full vendor catalog.
• Security — how Conduit encrypts and resolves the credential you just stored.