Agency Level API
under review
A
Anthony CRM Admin
I need the ability to add a contact into any subaccount. Having my agency API key with the ability to choose which subaccount to add a contact to would be tremendously helpful and reduce the number of complex coding and additional API keys needed to accomplish this.
Log In
S
Sales & Marketing
Merged in a post:
Agency Level In New Oauth API
S
Scott Heliker
From my understanding the V1 API will be deprecated eventurally. Currently we and others use this to automate insertion of API keys after a new account is created. We are not able to do this with the Oauth unless we can pass in and Agency API key when authorizing which then would allow us to populate a RPC with all the sub account under that Agency which then would allow us to map in the API keys in situations where we need things to happen dynamically.
Example. Creaeting a new sub acount and loading a snapshot thru the API then taking that response from the newly created account to update the custom values on that account. We can't do this without dynamically passing the API key from the new account to the update custom values endpoint dynamically.
There are a few othe instances we ourselves and I know many others use so I hope they consider and alternative with the Oauth by allowing us to pass in our Agency API keys so we have the option to make an Agency connection to then dynamically pass in locations we want to make the API call to.
M
Marty Mcclintock
you can share a contact by the corresponding agency admin owner email.
S
Somvir Singh
I fully support this request. As an agency owner, managing multiple subaccounts becomes unnecessarily complex without true agency-level API access. Right now, we’re forced to create and manage location tokens, which is inefficient, error-prone, and poorly documented. A unified agency API key with full functionality (contacts, calendars, automations, etc.) across subaccounts would save time, reduce coding headaches, and make integrations far smoother. This should be treated as a high-priority feature.
R
Remi Mayer
GoHighLevel White-Label OAuth Authentication Issue
## Problem
Users logged into a white-labeled domain (app.maxout.ai) are forced to log in again when accessing the OAuth consent screen on marketplace.leadconnectorhq.com, breaking the expected single sign-on experience.
## Technical Details
- White-label domain: app.maxout.ai
- Main GHL domain: app.leadconnectorhq.com
- OAuth endpoint: marketplace.leadconnectorhq.com
## Authentication Flow Issue
- User logs into white-label domain (app.maxout.ai)
- Authentication cookie (m_a) is set for app.maxout.ai domain
- OAuth flow initiated via:
```javascript
client_id=${clientId}&
redirect_uri=${redirectUri}&
response_type=code&
scope=${scopes}&
state=${encodeURIComponent(JSON.stringify(state))}&
loginWindowOpenMode=self`
);
```
- User redirected to OAuth consent screen with message:
> "Please login to your CRM to continue"
> "Note: If you are already logged in, please logout and login again."
## Root Cause
Cross-domain cookie restrictions prevent the OAuth endpoint from accessing the white-label authentication cookie:
- White-label auth cookie: Domain .maxout.ai
- Marketplace requires: Domain .leadconnectorhq.com
## Attempted Solutions
- Using marketplace.leadconnectorhq.com instead of marketplace.gohighlevel.com
- Adding loginWindowOpenMode=self parameter
- Attempting iframe approach to maintain authentication context
## Expected Behavior
Authentication state should persist from white-label domain to marketplace without requiring additional login.
## Questions for Support
- Is there a recommended approach for OAuth with white-label domains?
- How should authentication cookies be shared between domains?
- Are there specific white-label OAuth configuration settings?
- Should additional parameters be included in OAuth requests?
## Request
Guidance on properly implementing OAuth flow while maintaining white-label authentication context to eliminate double login requirement.
S
Scott Heliker
They have a create a location access token you can use to access sub account endpoints but agree, I thought they would have allowed access via the Agency token. For now, we create location tokens on the fly with the agency token and do it that way.
T
Tero Vaalamäki
We should have the ability to use subaccount calendars etc with the agency level authentication.
As long as I refer to the correct subaccount and calendar ID I should be able to access the calendar with my agency oAuth 2 credentials.
V
Vince Lauro
Edit: Sorted it. The API Doc seems to have a error on this page. https://highlevel.stoplight.io/docs/integrations/1a30b217da571-get-location-access-token-from-agency-token For some reason they removed the "authorisation: Bearer 123" in the sample code header so it kept returning a not authorised error.
A
Asmaa Mahmoud
Vince Lauro please can send me the correct payload required at this api when I use it unauthorized error is appear
V
Vince Lauro
Asmaa Mahmoud Its been a while but if I assume you are on the Step. "Get Location Access Token from Agency Token" you can try below request
curl --request POST \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Bearer 123' \
--header 'Version: 2021-07-28' \
--data companyId= \
--data locationId=
A
Asmaa Mahmoud
Vince Lauro when use this payload error changed to this {
"statusCode": 401,
"message": "The token is not authorized for this scope."
} i use token created from private integration from go high level agency account but when created new integration and put scopes i don't find scope oauth.write at dropdown can you know a problem?
V
Vince Lauro
Asmaa Mahmoud Hmm not sure. All I remember is that it was a huge pain especially before I found that bug in the sample. This video helped me a bit. https://www.youtube.com/watch?v=TtP0YSgIgk0
B
Bret Dunlap
Does any one know how to create a connection with the GHL Oauth 2 I can do it with the http Oauth 2 but cant seam to get the GHL module to connect
Core Platform
marked this post as
under review
E
Ed Preble
Would also like ability to create Snapshots using Oauth
Load More
→