By Legion Code Inc.

A growing set of small Chrome extensions that export, back up, restore, and version-control every facet of a GoHighLevel (HighLevel) sub-account — one focused tool per facet, for agencies and operators who keep their sub-account configuration in git.

R&D purposes only. This toolset is built and published for research and development purposes only. The tools talk to undocumented, internal HighLevel endpoints that can change or break without notice, and this project is not affiliated with or endorsed by HighLevel. Verify everything a tool produces before relying on it anywhere real.

A toolbox, not a monolith. Each tool in this repo is a standalone Chrome extension living in its own folder, with its own manifest and its own README. You install only the tool you need, and each tool does exactly one job against the sub-account you already have open in a tab.

This is a deliberate design choice: rather than one bulk extension that migrates or dumps everything from a sub-account in a single pass, the toolset covers the account facet by facet — workflows today, the other surfaces as focused tools as the set grows. Small tools are auditable in one sitting, fail independently, and can be pointed at exactly the data you want without touching the rest.

The first tool is live:

HighLevel has no built-in way to get a sub-account's configuration out as data you can diff, review, and restore. Agencies white-labelling GHL manage dozens of sub-accounts where a workflow edit is effectively irreversible — no history, no rollback, no code review.

Bulk export tools that exist are all-or-nothing: they assume you want everything, in one format, through one flow. Real operations need the opposite — pull the pipelines for a migration audit, snapshot the workflows before a release, diff custom values between two sub-accounts. That is a per-facet job, so this repo builds a per-facet toolset.

Every tool in the set follows the same contract, so behavior learned on one transfers to all of them:

• No credential handling. Tools borrow the page's own authenticated HTTP client (window.SHELL_STORE.$http) inside the tab you are signed into. No token is read, stored, or transmitted by the extension.
• Exports are read-only. Every request an export makes is a GET. Writes exist in exactly one place today — the workflow tool's Import tab — where they are always explicit, user-initiated actions: restores land as new drafts by default, overwriting a published workflow requires an extra acknowledgement, and nothing is ever published for you.
• Minimal permissions. activeTab, scripting, downloads. No host permissions, no background service worker, no remote code.
• Works on any GHL host. White-labelled domains included — tools never hardcode app.gohighlevel.com.
• Deterministic output. Sorted keys, fixed timestamps, and volatile fields (signed URLs, per-user permission metadata) stripped, so an unchanged sub-account re-exports byte-identically and git status stays quiet.

About a minute, no build step:

1. Open chrome://extensions.
2. Turn on Developer mode (top right).
3. Load unpacked → select the ghl-workflow-tools folder from your clone of this repo.
4. Open a HighLevel sub-account tab, click the extension icon, hit Export workflows.

• Chrome or a Chromium browser (Edge, Brave, Arc) with extensions developer mode available
• A signed-in session on the HighLevel sub-account you want to work with

git clone https://github.com/legioncodeinc/ghl-toolset.git

Then load the folder of the tool you want via chrome://extensions → Load unpacked, as in the quick start. Each tool's folder is self-contained; there is nothing to install or build.

Each tool has its own README with its exact flow — start with ghl-workflow-tools/README.md. The shared pattern across all of them:

1. Open the sub-account tab you care about (the tool shows which sub-account it detected).
2. Click the tool's icon and run its action.
3. An export lands as a ZIP in your downloads, shaped for unzipping straight into a git repo; a restore takes a previous export (.zip or loose .json) and writes it back — as drafts unless you explicitly overwrite.

A workflow backup session produces:

legendary-academy-<locationId>/
├── index.json         # one entry per workflow: name, status, version, counts
├── snapshot.json      # everything in one file, for diffing a release as a unit
├── README.md          # provenance note, written into every export
└── workflows/         # one re-importable JSON file per workflow

The goal is a focused tool for every facet of a sub-account that can be read through the app's own session. Planned, in no committed order:

• Pipelines and stages
• Calendars and appointment configuration
• Custom values and fields
• Email / SMS templates and media
• Funnels, websites, and blogs
• Forms and surveys
• Users and roles
• Whatever else the account exposes read-only through its own client

Each lands as its own folder here when it ships — not as modes piled onto an existing tool.

None, by design. No environment variables, no API keys, no options page — see .env.example for the rationale. Authentication travels with your signed-in tab and never leaves it.

Every tool is the same three-part shape (MV3, no build step):

flowchart LR
    A[Popup UI<br/>popup.html/js] -->|chrome.scripting<br/>MAIN world| B[Injected agent fns<br/>agent.js]
    B -->|borrows| C[App's own HTTP client<br/>window.SHELL_STORE.$http]
    C -->|same-session GETs| D[GHL backend<br/>backend.leadconnectorhq.com]
    B -->|results| A
    A -->|deterministic ZIP<br/>zip.js| E[Download]

• popup.js — orchestration: probes the tab, drives the export and import loops, builds files.
• agent.js — functions injected into the page's MAIN world. They must be fully self-contained (no imports, no closures) because they are serialized and re-parsed in the page.
• zip.js — dependency-free ZIP writer with a fixed timestamp, so identical content produces an identical archive.
• unzip.js — dependency-free ZIP reader (the browser's own DecompressionStream), so backups can be read back without third-party code.

git clone https://github.com/legioncodeinc/ghl-toolset.git
cd ghl-toolset
node scripts/validate-manifests.mjs

To work on a tool: edit its folder, hit reload on its card in chrome://extensions, and re-run it against a test sub-account. To add a new tool: create a ghl-<facet>-<verb>/ folder with a manifest.json, popup, agent, and README following the contract above — the validator and the tool table in this README pick it up. See CONTRIBUTING.md for the full workflow and CLAUDE.md for the codebase conventions in depth.

node scripts/validate-manifests.mjs

Passing looks like one ok line per tool manifest and exit code 0. This is the same check CI runs; beyond it, each tool is smoke-tested manually against a real (test) sub-account before release.

Releases are published by pushing a v<x.y.z> tag: the Release workflow validates every manifest, packages each tool folder as a ZIP (with a checksums.txt), and publishes a GitHub Release using that version's CHANGELOG section as the notes. To install from a release: download the tool's ZIP, unzip it, and load the resulting folder via chrome://extensions → Load unpacked. Extensions loaded unpacked never auto-update — a new release means downloading the new ZIP and replacing the folder. Chrome Web Store distribution is out of scope for this project. Exported data never transits any server — it goes from the browser tab to the ZIP on disk.

PRs welcome, especially for the roadmap facets above — one tool per PR, following the shared contract. See CONTRIBUTING.md for branching, commit conventions, and the local gate before opening a PR.

GHL Toolset is licensed under the GNU Affero General Public License v3.0. Each tool in the set carries the same license.

Copyright (c) 2026 Legion Code Inc.