Product

Automating Practice Onboarding: From Signup to Live Integration

A new customer signs up in your app at 9pm. By 9:01 they should be pulling their PMS data — with no email to your ops team and no one manually provisioning anything. Here is how partners wire the whole path into their own signup flow.

CRMBridge Team · June 4, 2026 · 8 min read
Signup form customer signs up Your App calls the API Onboarding API CreateBusiness CreateLocation provisions instantly Live /Auth APIToken pulling data

The gap between "signed up" and "sees value"

You have spent months making your signup flow smooth. The trial form is two fields. The welcome email is warm. And then the customer hits the part where they actually connect their practice management system — and everything stops. Someone on your team gets an email. Someone provisions an account by hand. Someone copies a key into a spreadsheet. Two days later, the customer who was excited on Tuesday is cold by Thursday.

That gap is where trials go to die. The distance between "customer signed up" and "customer sees their own data flowing" should be measured in seconds, not business days. It should not depend on whether your ops person is at their desk. It should not be a support ticket.

Onboarding should be an API call. When a customer completes signup in your app, your app should provision everything they need in CRMBridge programmatically, get back the credentials, and hand the customer a live integration — all before they close the tab. That is exactly what the Onboarding API is for.

First, how partners authenticate

Every Onboarding endpoint is authenticated at the partner level, not the practice level. You send two headers with every request:

PartnerID

Identifies you as the partner. Every business you provision is scoped to this ID.

PartnerAPIKey

Your OnboardingAPIKey. This is the secret that proves the request is really yours. Keep it server-side; it never touches a browser.

You find both in the developer portal under Settings → Onboarding API (you need the Admin role to see them), or your platform contact issues them to you directly. Store them the way you store any other server-side secret. Every call in the flow below assumes these two headers are present.

The end-to-end flow

Here is the whole path, from "customer clicked submit" to "app is pulling their data." Four steps, each one a plain HTTP call.

1. Create the business

POST /api/Onboarding/CreateBusiness registers the practice under your partner account and returns a BusinessID. If your partner account has a single App, the new business is auto-linked to it, so it can authenticate immediately — no extra step. If you have several Apps, pass the optional AppID to choose which one the business links to.

2. Create the location

POST /api/Onboarding/CreateLocation creates a location under that business and returns a LocationID together with a per-location APIKey. That key is what the on-prem integrator uses to identify itself when it phones home from the practice’s server. A business can have many locations; each gets its own key.

3. Authenticate for REST

Now switch from partner-level onboarding to practice-level data access. POST /Auth with your App’s ApplicationID and ApplicationKey (your AppID / AppKey — discover them with GET /api/Onboarding/Apps) plus the BusinessID and LocationID you just created. It returns an APIToken. That token is what every subsequent data call carries. The customer is now live.

4. The existing-business case

Onboarding a brand-new practice with a single App needs nothing extra — the auto-link in step 1 handles it. But for an existing business, or when your account has multiple Apps, call POST /api/Onboarding/LinkBusiness with the BusinessID and the AppID before you hit /Auth. That link is what tells CRMBridge which App is allowed to authenticate for that practice.

The whole sequence, in curl

Wire these three calls into your signup handler and onboarding is done before the confirmation page renders:

# 1. Create the business (auto-links to your single App)
curl -X POST https://api.crmbridge.ai/api/Onboarding/CreateBusiness \
  -H "PartnerID: 4821" \
  -H "PartnerAPIKey: pk_live_7f3c9a2b8e1d4056" \
  -H "Content-Type: application/json" \
  -d '{ "Name": "Maple Street Dental", "ExternalRef": "acct_90211" }'
# -> { "BusinessID": 130742 }

# 2. Create a location under that business
curl -X POST https://api.crmbridge.ai/api/Onboarding/CreateLocation \
  -H "PartnerID: 4821" \
  -H "PartnerAPIKey: pk_live_7f3c9a2b8e1d4056" \
  -H "Content-Type: application/json" \
  -d '{ "BusinessID": 130742, "Name": "Main Office", "Timezone": "America/Chicago" }'
# -> { "LocationID": 55810, "APIKey": "loc_2b9d17c4ee6a" }

# 3. Authenticate for REST -> get an APIToken
curl -X POST https://api.crmbridge.ai/Auth \
  -H "Content-Type: application/json" \
  -d '{
        "ApplicationID": 611,
        "ApplicationKey": "app_c084f1a6d92b",
        "BusinessID": 130742,
        "LocationID": 55810
      }'
# -> { "APIToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." }

Ownership and safety are built in

Every business you create is scoped to your PartnerID. You can create, list, and modify only your own businesses — there is no shared namespace to collide in and no way to reach into another partner’s tenants.

If you request a BusinessID that isn’t yours, the API returns a 404, not a 403. That is deliberate: a 403 would confirm the ID exists. A 404 leaks nothing — you can’t even tell whether another partner’s business is real. Your account only ever sees its own footprint.

To see everything you’ve provisioned, call GET /api/Onboarding/Businesses. It returns exactly the businesses under your partner account — useful for reconciliation, admin dashboards, or confirming a signup handler actually did what you think it did.

Lifecycle: churn, downgrade, and back again

Provisioning is only half the story. Customers cancel, downgrade, and come back. Two endpoints handle the rest of the lifecycle:

POST /api/Onboarding/DisableBusiness

Suspends a business when a customer churns or downgrades. Authentication stops working immediately. Nothing is deleted — the record and its history stay intact.

POST /api/Onboarding/EnableBusiness

Re-enables a suspended business when the customer comes back. They pick up exactly where they left off.

Both are reversible and idempotent. Disabling a business that’s already disabled is a no-op, not an error, so you can wire them straight to your billing webhooks without guarding every call. A failed-payment event disables; a successful re-charge enables. No human in the loop.

Why this matters for partners

When onboarding is an API call, your signup flow stops leaking customers at the integration step. Provisioning becomes self-serve, instant, and unattended. The customer who signs up at 9pm is pulling their PMS data at 9:01, and nobody on your team had to be awake for it.

This is the last mile of a signup flow. You already automated the form, the trial, the billing. The connection to the practice management system was the one piece that still needed a person — and now it doesn’t. Wire these calls in once, and every future customer onboards themselves.

Make onboarding a single API call.

CRMBridge lets you provision practices programmatically across 35+ practice management systems — create the business, create the location, authenticate, and hand your customer a live integration straight from your own signup flow.