APIs

Feature request — a read scope for workflow definitions The public API exposes workflow metadata (GET /workflows/, scope workflows.readonly) but no read path to workflow structure: triggers, waits, branches, and per-action configuration are not retrievable. That gap blocks a category of legitimate third-party tooling — configuration documentation, change auditing, QA review, and migration validation across subaccounts. Agencies inheriting an account today have no supported way to produce a written record of what a workflow actually does. Requested: a documented, read-only endpoint returning workflow structure, under a scope such as workflows.definition.readonly. Read-only is sufficient; no write access is being requested here. This is additive to the platform and benefits any developer building audit, documentation, or migration tooling, not only us.

Right now the Calendars API only lets us update Weekly Working Hours (the PUT /calendars/schedules/event-calendar/:calendarId endpoint, using wday type rules). That pattern applies to every future date until it's changed again. Date-Specific Hours, which can override a single date without touching the recurring pattern, only exists in the app UI. There's no way to set, update, or remove a date-specific override through the API. This makes it impossible to automate a very common scheduling pattern: a calendar whose available hours shift for one specific week, without disturbing every other week. My use case: I keep two scheduling links open in the same daily block, from 1 to 2 PM. Most weeks, Behind the Numbers gets 1 PM and Partner Networking gets 2 PM. But when a partner can only meet at 2 PM for one particular week, three or four weeks out, I swap the times just for that week. With only the Weekly Working Hours API, there's no way to automate that swap. Updating the recurring pattern to reflect one week's exception ends up changing the pattern for every week, not just the one I meant to adjust. Request: Add API endpoints (or extend the existing schedule endpoint) to create, update, and delete Date-Specific Hours for a given event calendar, the same way Weekly Working Hours can already be managed. Something like passing a date type rule alongside the existing wday type would fully solve this. This would let anyone with a calendar that shifts around occasional appointments automate those one-off changes instead of manually editing the UI every time, or accepting a recurring pattern that's wrong for most of the weeks it applies to.

When a field is updated via it can't be used as a trigger, when that same field is update manually and save it is used in the automation. This is crucial for scaling. PLEASE prioritise this, a tiny chang to allow API user updates used as well

A stable integration with Shopify is currently not possible, the customer cannot renew it every 24 hours

Use an endpoint like POST /smart-lists to create a smart list in order to be able to automate this

The proposal: stand up a public GitHub repository under the HighLevel org — call it gohighlevel-crm-public. No source code in it. It exists purely as an issue tracker: bugs, API failures, webhook problems, feature requests, and documentation gaps. WHY THIS MATTERS RIGHT NOW A large and fast-growing share of HighLevel integration work is no longer typed by hand. It is written by AI coding agents — Claude Code, Cursor, Copilot, Codex — working directly against the API on behalf of agencies and developers. When one of those agents hits a broken endpoint, an undocumented field, a 403 that should be a 200, or a webhook that silently never fires, the agent is holding the entire failing session in context: the exact endpoint and method, the headers, the request payload, the raw response body, the status code, the timestamp, the location ID, the auth type and scopes, and every step that led up to the failure. Today all of that context is thrown away. Hours later the developer opens a support chat and types a paraphrase from memory. The report that reaches HighLevel is a fraction of what the agent actually knew, and it is usually not reproducible. Multiply that by thousands of developers and it is an enormous amount of free, high-quality QA data that HighLevel is currently discarding. With a public repo, the whole thing collapses into one sentence from the developer: "Go ahead and file that as a bug." The agent then reads the issue template, searches existing issues for a duplicate, fills in every field from context it already has, and opens a clean, reproducible report. HighLevel builds no new tooling for this — coding agents already speak GitHub natively via the gh CLI. WHAT THE REPO WOULD CONTAIN No source code. Issues and Discussions only. The code stays private. Issue templates, so every report arrives in the same shape: - API failure — endpoint, HTTP method, auth type (OAuth vs API key vs private integration), scopes granted, request payload, full response body and status code, correlation or trace ID, timestamp with timezone, location and agency ID, expected vs actual behavior. - App or UI bug — browser and version, OS, white-label domain, sub-account vs agency view, user role and permissions, steps to reproduce, screenshot or screen recording, expected vs actual. - Webhook or automation issue — trigger, workflow ID, payload received, payload expected, delivery attempts and timing. - Feature request — problem being solved, current workaround, who it affects. - Documentation gap — page URL, what is wrong or missing, what the correct behavior turned out to be. A short CONTRIBUTING.md with the ground rules and a hard "scrub your PII, tokens, and API keys before submitting" warning that both humans and agents will read and follow. A label set — api, webhooks, workflows, billing, docs, confirmed, needs-repro, duplicate, shipped — so the board is triageable rather than a firehose. WHAT HIGHLEVEL GETS OUT OF IT Reproducible bug reports instead of paraphrases. Structured fields mean an engineer can act on the report without a round trip. Automatic deduplication. Agents search before they file, and duplicates get closed pointing at the canonical issue. One bug, one thread, instead of the same bug arriving forty times through forty support chats. Real signal on what is actually breaking. Issue volume by label tells you which endpoints fail most, which docs pages are wrong, and which features are most requested — measured, not guessed. Lower support load. Every answered issue is a permanent, searchable, public answer. The next developer who hits the same wall finds it instead of opening a ticket. Discoverability. Right now a developer who Googles a HighLevel API error lands on a Facebook group post from 2023 with no resolution. With this repo they land on an official thread with an official answer. A visible track record. Closing issues as "shipped" becomes a public, credible changelog of responsiveness. That is a genuine trust builder with the developer community. Goodwill with the builders. The people writing integrations against the API are the ones extending the platform. Giving them a real, public channel to report problems signals that HighLevel takes the developer surface seriously. GUARDRAILS WORTH STATING UP FRONT Issues only — no code is exposed, and no pull requests need to be accepted. The template makes PII and credential scrubbing an explicit, unmissable step. A stale bot can auto-close inactive issues so the queue stays manageable. Discussions can be enabled separately so open-ended questions do not pollute the bug queue. This does not replace support for account-specific or billing issues. It is specifically for reproducible product and API defects and for feature requests. The cost of trying it: one repository, five issue templates, a label set, and a triage owner. If it does not work, archive it. If it does work, HighLevel gets a continuous stream of pre-formatted, reproducible, deduplicated QA from every developer and every AI agent building on the platform — for free.

If you want to 10x your funnel output, THIS IS WORTH A 15 SECOND READ, because you're going to want to upvote this 👇👇👇 Look, we've all been there. Pulling landing page split-test data across accounts is brutal, and you know exactly what I'm talking about: 🔴 Pages sometimes load at the speed of a snail 🔴 LPs organized about as well as my desktop folders (they aren't) 🔴 And analyzing what's winning means clicking so much it makes you want to rage-quit and become a farmer At scale, it's hours every week that shouldn't exist. We didn't start agencies to become professional tab-openers. If GHL gives us landing page split-testing metrics via API or MCP, everything changes: ✅ View LP performance across every account in one place ✅ Analyze and iterate at scale (100s of clients) without the manual grind ✅ Speed to insight = faster funnel improvements = better client results ✅ MCP-enabled? Now we can create and test pages programmatically too I was about to pay $200/mo for standalone LP software just for this one use case, and most tools cost more than that. Bake this into GHL and it saves all of us that money. 👇 So here's the deal, fellow agency owners: if you run traffic at scale, PLEASE upvote this. The more of us behind it, the faster it ships. Let's get this built for the whole community. Thank you guys! 🙏

It would be great to have API support for the email preference centre, allowing us to create own own UI or host custom portals that include email preference management.

Allow me to pass and array of 100...1000 objects in one call so everything is not individual calls. The API throttling is too slow.