Skip to main content
Use this path to automate GHL account onboarding after your workspace has authorized the agency. Use the v3 authentication guide for key creation and handling.

Prerequisites

  • A workspace-level API key with subaccounts:create. A key restricted to selected subaccounts cannot create accounts.
  • Completed GHL agency OAuth for that workspace.
  • A location your agency is authorized to install.

Create or retrieve the account

Send the location ID alone as the creation mode:
Do not include name in this request: location_id selects GHL provisioning, while name selects Direct provisioning. Supply exactly one. A new account returns 201; an existing active account in the same workspace returns 200. Save the returned account ID. Retrying the same location does not create a second account. An archived/deleted account may be reactivated by this operation, so confirm that restoration is intended before sending it.

Request and response reference

There is no default creation mode: sending both fields or neither is invalid. The workspace comes from the API key, not a customer name or location label. The successful response’s account data contains: HTTP 201 means a new account was created. HTTP 200 means an existing account was returned or restored. workspace_forbidden is 403, ghl_not_connected and location_conflict are 409, location_not_found is 404, and an invalid creation mode is 400. Authentication, missing scope and rate-limit failures follow the v3 errors reference.

Verify onboarding

Read the returned account details and open that account in Assistable. Confirm its location and run the GHL connection check. Business-detail loading is best effort: provisioning can succeed even if GHL details could not be loaded, so inspect the name and timezone before deploying an assistant. See the v3 guide, errors, and account management.