Onboarding a customer

Conduit is built for MSPs serving their own customers. Each customer the MSP onboards is a separate organization underneath the MSP — fully isolated from every other customer, with its own users, vendor connections, and audit log, but administered by the MSP.

This guide walks through the customer-onboarding flow: how to create a customer, what happens immediately after, and where you go to manage the customer once it’s live.

For the underlying model — the MSP → customer → sub-customer hierarchy, transitive admin, and credential sharing — see the Subtenant Model.

---

Before you start

You need:

• An MSP organization in Conduit that you administer with an owner or admin role.
• The customer’s name and the email address of their owner (the person who will administer the customer organization once it’s set up).

Create the customer

From your Customers page:

1. Open Customers (/org/customers) and click + Add Customer. This opens the New Customer wizard.
2. Step 1 — Customer: enter the customer’s organization name. The URL slug is generated from the name automatically; adjust it if you’d like something different. The slug becomes the customer’s MCP endpoint URL: https://conduit.wyre.ai/v1/mcp/<your-slug>/<customer-slug>.
3. Step 2 — Admin: enter the email of the person who will own the customer organization. They’ll receive an invitation by email and set their own password via the link.
4. Step 3 — Review: confirm the summary and click Create customer.

Conduit creates the customer organization, sets you as the interim owner until the invitee accepts, and sends the owner invitation.

What happens immediately after

• The customer organization is created underneath your MSP organization.
• The owner you specified receives an email with an invitation link. When they accept, they become the owner of the customer organization; you remain an MSP admin who can administer it transitively (see Subtenant Model § Transitive admin).
• The customer’s MCP endpoint URL is live but, until a vendor is onboarded, no tools are exposed yet.

Adding vendors for the customer

There’s no dedicated onboarding wizard anymore. To connect a vendor for the customer, switch into the customer first: from Customers (/org/customers), click Manage on the customer’s row. This puts you into acting-as mode on the customer’s own organization — you land on their /org dashboard, with an acting-as banner showing you’re operating on their behalf.

From there, open Connections → Catalog (/org/catalog) and click Connect on the vendor you want. Conduit takes you to a one-step connect page (/connect/<vendor-slug>) — an API-key form or an OAuth redirect, depending on the vendor. That’s the per-user path: each person connects their own account, and their tool calls show up under their own identity in the vendor’s audit log.

Two other wiring patterns live on different surfaces, not in the Catalog flow:

• Shared org-level credentials — connect from Connections (/org/catalog) as an admin action; every user in the customer org goes through the one set of credentials you provide.
• Self-hosted (via a Tunnel) — a separate surface, Connections → Tunnels (/org/tunnels). The customer runs the vendor’s MCP server on their own infrastructure, reached through a small Conduit Tunnel. Credentials never leave their network. Best for strict data-residency requirements. See the Tunnel quickstart for the deploy steps.

Connecting a vendor doesn’t grant tool access by itself. Set the tier — and, optionally, a specific tool allowlist — from the connection’s Access editor afterward. See Managing access for how tiers, exceptions, and allowlists work.

Managing the customer

There’s no separate customer-detail page anymore. Administering a customer day-to-day means switching into acting-as (Manage from /org/customers) and using the customer’s own organization pages — the same ones the customer’s admins see:

Where	What it covers
Connections (/org/catalog; Tunnels under /org/tunnels)	Vendor integrations, connection status, and the per-connection Access editor.
Members (/org/members)	The customer’s users — invite, change role, remove. Roles are owner / admin / billing / member (see Permissions).
Audit Log (/org/audit)	Tool calls and administrative actions for this customer.
Org Settings / Domains (/org/domains)	Identity, claimed-domain auto-join configuration, and org-level policies (see MSP Onboarding § Invite team members).

Two exceptions don’t require switching — they’re reachable directly from the reseller side, re-chromed onto your own nav:

Where	What it covers
Usage (/org/customers/<id>/usage)	MCP call volume and active users (last 30 days), average response latency, and a per-vendor and per-source call breakdown for this customer.
Billing (/org/customers/<id>/billing)	The customer’s subscription state, rate, and invoices.

For the role model itself — what owner, admin, and member can do — see the Permissions reference.

Bulk provisioning via API

Customer creation goes through the reseller API. To onboard customers at scale, script against:

curl -X POST https://conduit.wyre.ai/admin/reseller/<your-reseller-id>/customers \
  -H "Cookie: gateway_session=<session>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Corp",
    "adminEmail": "owner@acme.example"
  }'

The endpoint creates the customer org and mints an owner-invite addressed to adminEmail. It returns the new customer’s id (and invitation_id), which you can use to switch into the customer (acting-as) and connect vendors from their Catalog. The body takes no plan field — under flat pricing every customer org is created on the single plan.

Suspending or deleting a customer

Suspend (POST /api/orgs/<id>/suspend) and delete are implemented at the API level. Suspend invalidates the customer’s user sessions and any live acting-as sessions into that org, and gates incoming tool calls while preserving data for re-enable. Delete is irreversible — connections, users, and settings are purged, while audit history is retained for compliance.

Note

There’s no UI control to perform suspend or delete — those remain API-only, run by your Conduit operator. Lifecycle state itself is visible, though: a suspended or deleted customer shows a Suspended or Deleted chip on your Customers list (in place of the Manage control — only Billing stays reachable), and the admin console’s org-detail page shows a matching banner with a restore hint (POST /api/orgs/<id>/restore).

Verification checklist

Before handing the customer off to steady-state:

• Customer created and the org’s subscription is in the expected state (trial or active).
• Owner has accepted the invite and signed in.
• At least one vendor connected for the customer (Catalog → Connect, shared credentials, or a Tunnel).
• At least one successful tool call visible on the customer’s Audit Log (/org/audit, viewed while acting-as).
• Tool allowlists match the customer’s access policy.

Related

• Subtenant model — the MSP → customer hierarchy and transitive admin.
• Permissions — the role model.
• Vendor connections — vendor catalog and credential-scoping detail.
• Tunnels — quickstart — the self-hosted wiring pattern, end to end.
• Connecting an AI client — what the customer's users do to connect their AI client to Conduit.