Two credentials — a location id and a private integration token — stored encrypted on the account row. Every GHL call anywhere in the app resolves them per-account, so one builder's contacts, media and conversations can never be read or written with another's identity. Legacy env-var credentials exist only as a bootstrap fallback for the original single-tenant account.
Also called: GHL integration · connect my CRM · HighLevel sub-account · location id and token
- 1Operator (or an admin, if the section is visible) enters the location id and private integration token.
- 2The token is verified against the claimed location before anything is stored.
- 3The token is AES-encrypted and written to the account row.
- 4Every GHL caller resolves credentials through getOrgGhlCredentials with a 60-second cache.
- 5Saving invalidates the cache so the next call uses the new values.
GoHighLevel has no API to mint a per-location token, which shapes the whole flow — ghlAgency.ts records it: 'HighLevel has no API to create a per-location Private Integration Token (PIT). After the location exists, WE (the platform operator) create a PIT in the new sub-account UI and paste it into the tenant's GHL setup panel.' The same file explains why the builder never gets a CRM login: 'We intentionally do NOT create a GHL *user* for the builder — GHL auto-sends new users a GHL-branded welcome email with no API flag to suppress it, and our builders never see GHL (we operate it for them).'
- Multi-tenant CRM access needed per-account credentials, not one shared key.
- Builders should not have to operate a CRM to use the platform.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →