MSP onboarding

This guide describes the end-to-end flow for onboarding a new Managed Service Provider (MSP) onto Conduit. It is written for the person standing up the MSP tenant — whether that is the MSP owner self-serving or a WYRE operator running a managed onboarding.

Most build-out steps can be done through the dashboard (paths below) or the API. The dashboard is the recommended path for first-time onboarding; the API endpoints are noted for teams automating provisioning. For exact API request/response shapes, see the API reference.

---

Phase 1: Discovery

Identify the vendor stack

Conduit is vendor-agnostic — the vendors configured for a deployment depend entirely on what the MSP uses. During discovery, inventory the MSP’s tool stack and decide which vendor integrations to enable.

Common vendor categories:

Category	Examples
RMM	Datto RMM, Syncro, Atera, SuperOps, ConnectWise Automate, NinjaOne
PSA	Autotask, HaloPSA, ConnectWise PSA
Documentation	IT Glue, Hudu, Liongard
Security	RocketCyber, SentinelOne, Huntress, Blumira, runZero
Email Security	Avanan, Avanan (Legacy SmartAPI), Proofpoint, KnowBe4
Network	Domotz
Sales	SalesBuildr, Pax8
Accounting	Xero, QuickBooks Online
Productivity	CIPP, Crewhu, TimeZest
Marketplace	Sherweb

The table lists examples — the vendors available in a given deployment are configured during onboarding. See Vendor Connections for how to add vendor integrations.

Gather requirements

• Team size — how many technicians will use Conduit?
• Role structure — who needs access to which vendors?
• Credential model — shared org-level API keys, or per-team / per-user keys?
• Compliance needs — do they require audit log export or SIEM integration?
• MCP client preference — which MCP-compatible client the technicians use (any works — Claude Desktop, Claude Code, Cursor, and others), or custom automation via service accounts?

---

Phase 2: Build-Out

1. Create the organization

The MSP owner creates an org from the dashboard, or via the API:

POST /api/orgs
{
  "name": "Acme MSP"
}

The org starts on a free 14-day trial of the full platform automatically. Hosted /signup collects a card with no charge during the trial; POST /api/orgs and self-hosted deployments can skip the card field. You can cancel any time from your account settings.

2. Activate your subscription

Manage billing from the billing page at /org/billing. There is no separate activation step.

The subscription includes the full platform — every feature, no gates:

• Unlimited vendor connections
• Standard rate limits per vendor
• Full team features (members, roles, invitations)
• Role-based access (per-vendor, per-role tool scoping)
• A clear record of every tool call, with CSV export
• Log shipping to SIEM (Huntress, Splunk, Elasticsearch, Microsoft Sentinel, Loki, Graylog, LogScale, or any HTTP JSON intake)
• Prompt capture
• SSO and service accounts (M2M)

See the Billing & Plans guide for the flat pricing detail.

3. Connect vendor credentials

For each vendor the MSP uses, configure credentials at the org level from the connections page at /org/catalog:

• API-key vendors (most vendors) — click Connect next to the vendor and enter the required API keys/secrets.
• OAuth vendors (Xero, QuickBooks Online, Calendly) — click Connect and complete the OAuth flow. Conduit handles token exchange and stores refresh tokens for automatic renewal.

Credentials can also be stored via the API:

POST /api/orgs/:orgId/credentials/:vendor
{ "apiKey": "...", "apiSecret": "..." }

See the Security guide for how credentials are encrypted and resolved.

4. Configure vendor access

With no grants, nobody but the owner has vendor access — access is deny-by-default. Manage who can use each connected vendor, and at what level (Read/Write/Delete/Admin), from that vendor’s Access editor on the connections page at /org/catalog. Start each vendor’s Everyone row at the level most members need (often just Read), then add per-member or per-team exceptions. The Everyone row is what every new member — and every new ordinary service account — picks up automatically, so set it deliberately. See the Managing access guide for the full editor walkthrough.

Legacy API

PUT /api/orgs/:orgId/members/:userId/server-access still exists and still grants access, but only as a blunt, all-or-nothing admin-tier grant to one vendor for one member — it can’t set Read/Write-only access or a tool allowlist, and it has no dashboard page anymore. New setups should use the Access editor instead.

5. Set up teams (optional)

For MSPs with distinct groups (e.g. “Tier 1 Support”, “Security Team”, “Accounting”), manage teams from /org/teams:

POST /api/orgs/:orgId/teams
{ "name": "Tier 1 Support" }

Teams can carry their own vendor credentials (separate API keys) and their own vendor access grants.

6. Configure tool allowlists (optional)

Restrict which specific tools a member or team can call per vendor from the same Access editor (/org/catalog) — expand a group (Read/Write/Delete/Admin) on the Everyone row or an exception row and hand-pick individual tools instead of checking the whole group. Owners always have full access; leaving a group unchecked means no tools in it are available. See Managing access § Restrict to specific tools.

Legacy API

PUT /api/orgs/:orgId/tool-access/:vendor/:role still exists, still works, and still narrows tool calls — it is not superseded by the Access editor. It sets a role-wide allowlist that is combined (AND) with whatever the Access editor grants, so a leftover role allowlist here can silently block tools the Access editor otherwise permits. There is no dashboard page for it; use it only if you already rely on it, and prefer the Access editor’s per-tool selection for new configuration.

7. Invite team members

Generate invitation links from /org/invitations:

POST /api/orgs/:orgId/invitations

This returns an invitation URL. Share it with team members — when they visit the link and sign in, they join the org as a member.

Claimed domains — auto-join without invitation links. From /org/domains, verify your organization’s email domain and anyone who signs up with an address on that domain files a join request instead of needing an invite link (see Changelog § Claimed domains with auto-join). Verification is a DNS TXT record: add _conduit-verify.<your-domain> with the value shown on the page, then click Verify — this always works regardless of your DNS provider. For some providers, a one-click button may also appear alongside the manual record to add the TXT record for you; if it doesn’t appear, or doesn’t work, the manual steps above are the reliable path.

The owner can promote a member to admin or billing from /org/members — role changes are owner-only, admins cannot change anyone’s role (see Permissions § Member-management guardrails):

PATCH /api/orgs/:orgId/members/:userId/role
{ "role": "admin" }

The owner can also transfer ownership itself to another existing member from /org/members — the previous owner becomes an admin in the same action:

POST /api/orgs/:orgId/transfer-ownership
{ "user_id": "<existing member's user id>" }

8. Create service accounts (optional)

For machine-to-machine automation (AI agents, scripts, integrations), create service accounts from /org/service-clients:

POST /api/orgs/:orgId/service-clients
{ "name": "Nightly Ticket Sync", "expires_in_days": 90 }

This returns a client_id and client_secret (shown once). The service account authenticates via the client_credentials grant and receives a JWT scoped to the org.

A new machine-to-machine service account starts with each vendor’s Everyone default, exactly like a new member — so with permissive Everyone rows it can reach more than you intend. Scope it before handing out the credentials: add it to a team on /org/teams (it then follows that team’s grants, like a human member), or give it an override from the vendor’s Access editor. A Microsoft 365 Copilot connector client (created with redirect_uris) is the exception: it starts with an explicit Read grant on every vendor connected at that moment — see the Copilot guide. See Managing access.

9. Configure log shipping (optional)

For compliance or monitoring, ship audit logs to an external SIEM from /org/log-shipping — Huntress Managed SIEM, Splunk, Elasticsearch, Microsoft Sentinel, Grafana Loki, Graylog, Falcon LogScale, or any HTTP JSON intake. Per-platform setup is in Log shipping to your SIEM.

---

Phase 3: Go-Live Checklist

• Organization created and subscription active (or in trial)
• All required vendor credentials connected and validated
• Vendor access configured per connection (Access editor at /org/catalog) — defaults and any per-member/per-team exceptions
• Tool access restricted per connection (Access editor) where needed
• Team members invited and accepted
• An MCP client (Claude Desktop, Claude Code, Cursor, or any MCP-compatible client) configured with the Conduit server URL
• Service accounts created for any automation workflows
• Audit log verified — make a test tool call and check /org/audit
• Log shipping tested (if configured)
• MSP owner has verified access to the billing portal at /org/billing

Client configuration

WYRE-hosted Conduit endpoint

For new setups, use https://conduit.wyre.ai/v1/mcp — the recommended endpoint for the WYRE-hosted Conduit service. Existing clients configured against https://mcp.wyre.ai/v1/mcp continue to work without changes (same gateway, same auth — no migration needed).

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "conduit": {
      "url": "https://conduit.wyre.ai/v1/mcp"
    }
  }
}

Claude Code:

claude mcp add --transport http conduit https://conduit.wyre.ai/v1/mcp

On first use, the OAuth flow opens a browser for authentication. After sign-in and credential connection, the JWT is cached and refreshed automatically. See the Security guide for details on the OAuth 2.1 + PKCE flow.

---

Phase 4: Ongoing Support

Monitoring

• Audit log — /org/audit (dashboard) or GET /api/audit with filters for user, vendor, and date range
• Admin audit — GET /api/audit/admin for administrative action history

Common operations

Task	Where
Add a team member	/org/invitations
Remove a member	/org/members
Rotate vendor credentials	/org/catalog (overwrites the existing credential)
Manage vendor/tool access	/org/catalog → a connection’s Access editor
Change a member’s role (owner-only)	/org/members
Transfer ownership (owner-only)	/org/members
Export the audit log	/org/audit → Export CSV
Manage billing (owner or billing role)	/org/billing
Set the invoice recipient (owner or billing role)	/org/billing

Credential rotation

When rotating vendor API keys, update the credential at the appropriate scope:

• Org-level — /org/catalog
• Team-level — the team-filtered Catalog (/org/catalog?team=<teamId>), reached via the team’s Connections button on /org/teams
• Personal — /settings/profile (the individual user reconnects)

Conduit encrypts the new credential and begins using it immediately. The old credential is overwritten.

---

Onboarding customers under the MSP

The steps above stand up the MSP’s own organization. Onboarding the MSP’s customers as sub-organizations — and the MSP → customer hierarchy that governs them — is covered separately:

• Subtenant Model — how the MSP → customer → sub-customer hierarchy works

Frequently asked questions

Who is Conduit onboarding for — can I self-serve?

The flow works whether the MSP owner is self-serving or a WYRE operator is running a managed onboarding. Most build-out steps can be done through the dashboard, the recommended path for first-time onboarding, or via the API for teams automating provisioning.

What should I gather before onboarding?

During discovery, inventory the MSP’s tool stack (which vendor integrations to enable), the team size, the role structure, the credential model (shared org-level keys versus per-team or per-user keys), compliance needs such as audit export or SIEM integration, and the MCP client preference — any MCP-compatible client works (Claude Desktop, Claude Code, Cursor, and others), or service-client automation.

How does billing start during onboarding?

A new organization begins with a free 14-day trial of the full platform automatically. Hosted signup asks for a card; there is no charge during the trial, and you can cancel any time from your account settings. Self-hosted deployments can skip the card field. Conduit is one flat plan — see the Billing & Plans guide for the pricing detail.

How do I control which vendors and tools a member can use?

Open the connection’s Access editor from /org/catalog — set the Everyone row’s Read/Write/Delete/Admin checkboxes as the default, then add per-member or per-team exceptions for anyone who needs more or less. To restrict specific tools, expand a group and hand-pick them instead of checking the whole group. Owners always have full access. See the Managing access guide.

How do I connect an MCP client once the tenant is built?

Point your MCP client — Claude Desktop, Claude Code, Cursor, or any MCP-compatible client — at the Conduit server URL (https://conduit.wyre.ai/v1/mcp). On first use an OAuth flow opens a browser for authentication; after sign-in and credential connection, the token is cached and refreshed automatically.