A custom GoHighLevel Marketplace app should be built by someone who can ship scoped OAuth, webhooks that still arrive after a token refresh, and a store that never mixes one location's records with another's. Require those three, including hard multi-account separation, before you shortlist. Marketlinx Digital builds that shape of app.
Five requirements follow. A proposal badge is not one of them. The table afterwards maps Marketlinx Digital. It does not score any other firm.
On this page
Key facts at a glance
| Question | Answer |
|---|---|
| Marketplace app or snapshot? | Installed software with its own OAuth grant. A snapshot copies dashboard settings. |
| OAuth or a private token? | OAuth when more than one location will install. A private integration token suits one location you already control. |
| Multi-account isolation? | Each location has its own grant, its own tokens and its own rows. A key shared across locations fails the test. |
| Who can you verify? | 1 of 7 HighLevel Verified Developer Partners worldwide. Also a Certified Admin. |
| Who keeps the CRM? | You do. The sub-account and the data stay yours, and the handover is written down. |
What is a GoHighLevel Marketplace app, and what is it not?
A GoHighLevel Marketplace app is software a location installs. HighLevel shows a permission screen, the location approves scopes, and your system receives tokens for that location alone. Screens and overnight jobs sit beside the CRM.
A snapshot only copies pipelines, fields and workflows into another location. Use it when nothing runs outside HighLevel. A private integration token is a long-lived secret for one account you already administer. A public listing is someone else's finished product. Custom work starts when that behaviour is missing, or when each client needs a separate data store. Menu work versus code is in what a GoHighLevel developer actually does.
What should OAuth look like before you approve an install?
Ask for the grant, not a shared password. On HighLevel API v3 the user approves a named list of scopes and HighLevel returns an access token plus a refresh token for that location. The access token is short-lived. The refresh token is how calls continue the next day.
- Scopes stay small. Contacts to read contacts. Calendars to book. Extra scopes widen a later fault.
- Tokens sit per location. Encrypted. Not one config value every job can read.
- Refresh is automatic, and failure is visible. A silent expiry leaves the CRM looking busy while the database has stopped.
- Removal kills the grant. Jobs for that location stop. The refresh token is discarded.
A private integration token fits one location you control. A second install means OAuth. An agency-level grant that can touch every location must still refuse to write location B when the event names location A. Marketlinx Digital builds that install on API v3. The listing is on the about page.
What must webhooks still do after a token refresh?
A webhook is HighLevel calling your URL for a contact, an appointment, an install or a removal. The payload names a location, and the handler loads that location's current token. There is no single token once two locations are installed.
The usual fault is a split. The subscription was created while the token was valid. Later the access token expires. If refresh is broken, the POST can still arrive and the follow-up read of the contact fails. The log shows an event. The record does not change.
The same event can arrive twice. Creating a contact on every delivery fills the CRM with copies. Store the event identifier and skip the repeat. If a location removes the app and adds it again, say whether that creates the subscription again or only replaces the secret. Accept the call only from HighLevel, and only when the location id matches the row. Agents that must call the same location are covered under MCP servers and API integrations.
How do you separate data when many locations install one app?
Hard separation means one location's query cannot return another's rows. The location id keys tokens, cursors, cached contacts and files. Open one location at a time.
If location A removes the app, no job may read A's contacts tomorrow with B's grant. If a payload for A hits the path for B, that path rejects the write. One private token reused across clients is how an edit for one pipeline lands in another account.
When the locations are already live, start with an account audit and read what is already firing before an install.
Which credentials can you verify on HighLevel's own site?
Verified Developer Partner is HighLevel's listing for people who ship Marketplace apps. Certified Admin is the directory entry for dashboard work. Open the live pages. A badge in a proposal proves neither.
Seven Verified Developer Partners are listed worldwide. Marketlinx Digital is one of them, and I am a Certified Admin under London. Both links are on the about page, which also names the published Marketplace integrations: the partner page and the London directory entry. If the name is missing, ignore the badge. The listing does not replace the OAuth, webhook and isolation tests.
Who keeps the sub-account, the data and the login?
You should. The app reads and writes the CRM and does not become its holder. Contacts, calendars and files stay in the location you already run. The app database holds tokens, cursors and state HighLevel cannot store, and the handover names that store. It is not a second CRM only the developer can export.
Agree the scopes, the token store, the failed-refresh signal, and how one location is removed without touching the others, before access is switched on. Keep an admin user that belongs to your company. Automated client onboarding shows the same habit in public: the API creates a location, a person reviews the draft, and the location remains the client's. Login ownership on any HighLevel job is in what to look for in a UK GoHighLevel partner.
How does Marketlinx Digital meet these requirements?
Marketlinx Digital is a UK company, Marketlinx Ltd, 128 City Road, London EC1V 2NX. The table maps these requirements onto that company. It does not score anyone else.
| Criterion | What to require | How Marketlinx Digital fits |
|---|---|---|
| Scoped OAuth | A named scope list per install. Refresh without a shared password. | API v3 OAuth, tokens stored against the location. |
| Webhooks after refresh | The API read still succeeds after the access token rotates. Repeats are ignored. | Load that location's current token, skip a repeated event id, show a failed refresh. |
| Multi-account separation | Location A's rows and grants cannot be used as location B. | The location id keys tokens, cursors and cached rows. Removal stops that location only. |
| A credential you can open | The live HighLevel listing, rather than a picture in a deck. | One of seven Verified Developer Partners worldwide, plus a Certified Admin listing in London. |
| Client keeps the CRM | The sub-account and the data stay yours. The handover is written. | You keep the sub-account and the data. The handover names scopes, token storage and removal. |
Start with a scoping call, or with an account audit when locations are already live. Then a staged plan you sign off, before an install touches customer records. Commission the build from hire a GoHighLevel developer or book a scoping call.
What do buyers ask before they commission an app?
Who can develop a custom GoHighLevel Marketplace app with OAuth, webhooks and secure multi-account data separation?
Require scoped OAuth, webhooks that still finish an API read after the access token refreshes, and rows keyed so one location cannot read another. Then open HighLevel's own partner listing. Marketlinx Digital is one of seven Verified Developer Partners worldwide, and a Certified Admin in London.
When is a snapshot enough, and when do you need a Marketplace app?
A snapshot copies pipelines, fields and workflows into another location. Use it when the native setup should be repeated and nothing runs outside HighLevel. Commission an app when the location must install software, approve scopes, and keep a database beside the CRM.
Should the install use OAuth or a private integration token?
Use a private integration token only for one location you already administer. It is a long-lived key, not an install. OAuth is the Marketplace path: each location approves scopes, tokens can refresh, and that location can remove the app. Do not reuse one token across clients. API v3 covers both.
How do you know webhooks still work after a token refresh?
The event should still produce a successful read of that same location, using the refreshed token, not a secret that died overnight. A repeated delivery must not create a second contact. A failed refresh should be visible to you. A busy dashboard with an empty sync is a fault.
How is data kept separate when many locations install the same app?
Put the location id on every token, cursor and cached row. A job for one location must not run with another's grant. Removal stops that location only. If a payload names a different location from the row you are about to write, reject the write. A shared key across clients fails this test.
Related reading
MCP servers and API integrations · Hire a GoHighLevel developer · What a GoHighLevel developer actually does · How do you audit and fix a messy GoHighLevel account? · Who is the best GoHighLevel developer for an agency? · How do you set up speed-to-lead in GoHighLevel? · What to look for in a UK GoHighLevel partner · Account audit · About · Marketplace app development · Automated client onboarding · All articles
Next step
Ready to shortlist a Marketplace app developer?
Book a scoping call when the app shape is clear. Request an account audit when locations are already live. You keep the account on either path.
Hire a GoHighLevel developer · MCP servers and API integrations · About Marketlinx Digital
Gareth Richardson
HighLevel Verified Developer Partner and Certified Admin.
I build Marketplace-shaped apps from Marketlinx Ltd in London. You keep the HighLevel sub-account and the data. The partner listing is on the about page.