What actually works in GoHighLevel automation

The task. Create a login (a rep, a client admin) through the API.

What we found. POST /users/ with a location-level Private Integration Token returns 401 "not authorized for this scope". User creation is agency-scoped. No location scope unlocks it.

Lanes that work. An agency-level OAuth app (marketplace app installed at the agency) can mint users. Otherwise it's a one-click UI create — define the role once (User + Only-Assigned-Data on) and hand off the click.

Evidence. Confirmed live against a production sub-account; the 401 is consistent and immediate.

The task. Set custom win probabilities per pipeline stage so forecast dashboards read correctly.

What we found. stageWinProbability is not user-editable. PUT /opportunities/pipelines/{id} returns 401 with every scope enabled; every PATCH/POST/PUT against /opportunities/pipelines/{id}/stages/{stageId} returns 404 — the routes don't exist. The Stages tab has no probability editor; clicking the stage name opens an inline rename. HighLevel auto-distributes 11.11 × position, so eight stages get 11.11, 22.22 … 88.89, and your "Won" stage shows 77.78%.

What it affects. Nothing functional — workflows key on stage id. Only the forecast/funnel dashboards, which show the auto values. Tell customers who read those dashboards literally what the numbers mean.

Evidence. Confirmed by HighLevel support and by five separate API and UI probes. Don't spend another afternoon on it.

The task. Edit an email action the AI builder created, and have your edit stick.

What we found. Every Send Email action generated by "Build using AI" arrives with From Email = "/". That fails inline validation ("Invalid email"), which blocks Save — and the builder doesn't tell you. Your body and subject edits revert on the next panel switch.

Fix. Clear From Email to empty. Blank means the location's default sender, which sends fine. Then re-open the action after saving to confirm the subject and body persisted — panel switches can scramble bodies, so read back before you trust a write.

Evidence. Reproduced on every AI-built email action we touched. Clearing the field made Save succeed each time.

The task. Drive the workflow builder (or the pipeline builder) with an automation agent.

What we found. The builder is served from a different origin than the app shell (client-app-automation-workflows.leadconnectorhq.com). Extension-based browser agents can see it but their clicks never dispatch into it — every action silently does nothing. Playwright drives it completely: locate the frame with page.frames().find(f => /automation-workflows/.test(f.url())) or iframe[name="workflow-builder"].contentFrame(), then read and click inside that frame as normal.

Gotchas. Canvas nodes are sometimes intercepted by the toolbar overlay — use {force: true} on those clicks. The builder needs a real logged-in session; seed a Playwright browser context once with a human login and reuse it.

Evidence. Built, edited and published workflows end to end through the frame across multiple sub-accounts. Extension-lane attempts confirmed inert on the same targets.

The task. Understand why a published workflow "isn't firing."

What we found. Settings → Communication → Time window "Specific time" restricts all actions in the workflow to the configured days and hours — not only SMS and email. Anything enrolled outside the window sits in waiting until the window opens. There is no warning on the canvas.

Fix. For transactional, Day-0, demo, or any always-on workflow: turn the window off. Reserve it for genuinely marketing-only sequences.

Evidence. The original "won't send" report was a Saturday test against a Mon–Fri window. Disabling it sent the queue instantly.

The task. Build a transactional or 24/7 workflow with the AI builder and have it actually send outside business hours.

What we found. The AI builder almost always adds Settings → Communication → Time window → "Specific time", set to Monday–Friday 08:00–17:00. Every action in the workflow then waits for the next window. Emails show as waiting with no error. It looks broken. It's scheduled.

Gotchas. Nothing in the builder's confirmation mentions the window. First time we hit it, a Day-0 welcome email "wouldn't send" — tested on a Saturday.

Fix. After any AI build, open Settings and turn the time window off before you publish.

Evidence. Reproduced on multiple AI-built workflows. Turning the window off released the held actions immediately.

The task. Add a stage to an existing pipeline with Playwright.

Path. Opportunities → Pipelines → the row's ⋮ menu → Edit → Add stage → name it → Save.

What we found. Entering the stage name with fill() leaves Save disabled. The form is Vue; its "all stages must have names" check only clears when a real keystroke fires reactivity. page.keyboard.type(name) works; fill() doesn't.

Gotchas. The new stage lands at the end. Drag-reordering is cosmetic — workflows key on stage id, not position, so you rarely need to.

Evidence. Reproduced across several sub-accounts; the keystroke method has not failed since.

The task. Create, publish, disable, or edit a workflow programmatically.

What we found. There is no write endpoint. GET /workflows/?locationId=… returns names, ids and status, and that is the whole surface. We probed five plausible write paths against a Private Integration Token with every scope enabled — PUT /workflows/{id}, PATCH /workflows/{id}, PUT /workflows/{id}/status, POST /workflows/{id}/draft, POST /workflows/{id}/disable — and every one returned 404. The routes don't exist.

What this means. Every workflow change is a UI action. If you need it automated, the lane is the native AI builder to scaffold, then Playwright inside the builder iframe to finish. See the cross-origin iframe verdict for the mechanics.

Re-check when. If HighLevel ships a workflow write API or expands PIT scopes. Until then, stop probing — this one is settled.

The task. Add and manage Voice AI agent actions programmatically instead of through the builder.

What works. POST /voice-ai/actions creates standard actions — for example actionType: IN_CALL_DATA_EXTRACTION targeting a contact custom field returns 201. Publish with the documented round-trip: GET the agent, strip id, actions, traceId and toolCallStrictMode, then PUT /voice-ai/agents/{id}?locationId=…&publishAgent=true. Verified: the new action present exactly once, existing actions untouched, persona unchanged.

What doesn't. Custom Action 2.0 (the HTTP-request action) can't be created through that endpoint. Three payload shapes — including the exact actionParameters a working custom action returns on GET — all came back 422 "Invalid actionParameters for the given actionType".

The lane. Create the custom action once in the builder wizard; from then on it's readable and updatable via API like the rest.

Evidence. Reproduced against a live agent in a production sub-account.

The task. Have a Voice AI agent reliably write what the caller said into contact fields.

What we found. Update-contact-field capture actions set to fire during the call get skipped when several compete — on a real call where the agent had every detail in conversation, zero of nine captures fired. The contact record held only the phone number. Switching the same actions to after the call made capture consistent.

Second defect to check. Capture actions created without a target field ("Please select" left in place) can never write anywhere and fail silently. Audit every capture action's target.

Fix. Set all field-backed captures to after-the-call. Verify each has a real target field. Keep during-the-call only for values another action needs mid-conversation, and keep those to one or two.

Evidence. Diagnosed on a production agent with blank-field alerts; corrected configuration captured every field on the next test call.