Uxie Ghl Factory

uxie-ghl-factory

A plugin that turns **Claude Code** — or **Codex** — into a competent **GoHighLevel operator**: it reads a sub-account, designs and builds workflows, courses, funnels, events, pipelines and AI agents, and reverse-engineers GHL's own internal APIs when the public one falls short.

Install in Claude Code

/plugin marketplace add uxieee/uxie-ghl-factory
/plugin install uxie-ghl-factory@uxieee

Then run `/uxie-ghl-factory:setup` for the public rail, and `/uxie-ghl-factory:internal-connect` for the internal one.

Install in Codex

codex plugin marketplace add uxieee/uxie-ghl-factory
codex plugin add uxie-ghl-factory@uxieee

The Codex build ships the **skills only** and does **not** bundle the MCP servers — configure them yourself (one-time). Slash commands are Claude Code-only. See **[Using in Codex](#using-in-codex)**.

---

The two rails

Almost every decision here comes down to which one you are on.

	Public rail	Internal rail
What	GHL's official, documented v2/v3 API	the same endpoints GHL's own web app calls
Auth	a Private Integration Token, long-lived	a browser session JWT, ~1 hour
Surface	671 operations across 45 categories	806 catalogued endpoints
Server	@uxieee/ghl-mcp (npm, runs locally)	uxie-ghl-internal-mcp (bundled, local stdio)
Status	supported, stable	undocumented, can change without notice

Default to public. The internal rail exists because the public API cannot reach the workflow builder, memberships and courses, events, funnel/page content, Voice AI behaviour, or knowledge bases at all.

Inspecting your own account's traffic is permitted; what GHL does not owe is compatibility. Every internal write passes two gates — an owned-account check each session, and a one-time acknowledgement per workspace.

Finding things — the same shape on both rails

Neither rail asks you to know an endpoint in advance.

public    search_actions   →