verifyGhlTokenLocation performs a GET against /locations/{id} with the supplied token. A 401 or 403 means the token belongs elsewhere and the save is refused with an explicit message. Every credential save path must pass this check.
Also called: wrong token · cross-tenant guard · token scope check · another business's data
- 1Admin or operator submits a location id and token.
- 2The route calls the CRM's location endpoint with that token.
- 3401/403 returns a refusal explaining that storing it would route this account's data into another business's sub-account.
- 4Only a clean response allows the encrypted write.
This is a SEV-1 fix, recorded verbatim: 'GHL enforces token↔location scope on GET /locations/{id} (403 for a foreign location) but NOT on every endpoint — pipelines, for one, quietly returns the token's own data whatever locationId you claim. That gap let a Barnhouse-scoped token be stored as Graber's credential, and every Graber-context media upload landed in Barnhouse's library (SEV-1, L2B cross-tenant incident 07-30). Every credential save MUST pass this.'
- A mis-scoped token could be stored and silently route one builder's data into another's CRM.
- The vendor's own API does not enforce scope on every endpoint.
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 →