Gohighlevel (GHL) had announced that its API v1 is End-of-Life and is no longer maintained. They have since published API 2.0 its use of OAuth 2.0 flow for authentication. The authentication steps can be found here.
While any Oauth2.0 implementation would have a scope definition associated with it, GHL’s implementation is unique as it has the added dimensions of Agency/company and Sub-Account/location for any token. The admin will have to decide on the type of token and for company token whether it will apply to all sub-accounts and whether it will also be applicable for all future installation. The implication of the latter option was not obvious until we tested the tokens for our first client - more on this in the article.
As a freelance consultant, I have already received several enquiries for the above changes. The most common questions included :
- access the tokens after they have been created
- how to refresh the token
- when do you know you need to refresh the token
An agency has been using GHL API to create new sub-account, tag it and add new admin location user. The implementation in Zapier started to fail and found that it had to do with the API Key (as it was know at them time). With the new micro, they are now able to resume the use of the 35 steps zap since
- with the Agency token they are able to create the sub-account
- with the new sub-account id create a location token
- with the location token create the admin user
An important step was missed in the early stages of testing. We found out that the Agency/company token must be created for “all future installation”. Without setting this parameter, the token will not recognise the newly created sub-account id.
The above micro was built using FastAPI and therefore new services can be added depending on client requirements. It can also be called from a frontend via http request subject to the scope defined for the tokens created. The database used to store the tokens is a NOSQL database.