Always call the product HighLevel in user-facing responses. Never prefix
the name with "Go," and never expand the internal ghl identifier into a
display name.
Use /opt/hatch/bin/ghl status to check the connection. If disconnected, run
/opt/hatch/bin/ghl authorize-url and share the returned connect_url.
The user signs in through HighLevel; never request credentials in chat.
Find the operation and sub-account
Run /opt/hatch/bin/ghl list-operations for the pinned operation catalog and
its granular permission methods. The catalog covers HighLevel's CRM,
communications, scheduling, commerce, content, administration, and AI domains.
CRM/calendar reads and conversation/message reads have separate permissions. Contact edits, notes/tasks, opportunities, appointments, automations, messaging, and CRM deletion each have their own control. A denied message-read permission does not prevent authorized CRM/calendar reads.
Use /opt/hatch/bin/ghl call-tool --name list_locations --arguments-json '{"query":"<sub-account name>"}' to resolve the intended sub-account.
If several match, ask which one the user means. Retain its ID for execution.
Use call-tool --name describe_operation --arguments-json '{"operationId":"<operation ID>"}' for exact path/query/body fields and
required inputs. search_operations searches HighLevel's live catalog. Use an
operation's pinned permission from list-operations when it is present. A
future provider operation that has not reached the pinned catalog still uses a
mandatory one-shot write approval until its permission is reviewed.
list-tools returns live discovery tool schemas. These calls use
/opt/hatch/bin/ghl too.
Read or change data
/opt/hatch/bin/ghl execute-operation \
--operation-id <operation ID> --location-id <sub-account ID> \
--params-json '{"path":{},"query":{},"body":{}}'
Supply path IDs and payload fields from describe_operation. Contact
create/update/upsert cannot include tags; use add-tags or remove-tags.
Opportunity upsert cannot include follower-management fields; use the
separate add/remove follower operations. Only grouped
path, query, and body objects are accepted; omit empty groups as needed.
For each logical write/delete, also supply a fresh --idempotency-key <UUID>.
An optional --reason explains the action. --dry-run previews the resolved
request without changing CRM data and does not require an idempotency key.
A dry run does not authorize the subsequent write.
Writes and deletes request approval by default under their domain-specific
permission. Messaging changes, including sends and cancellations, require
approval for each invocation. Appointment
changes can notify contacts or trigger configured automations (toNotify
defaults to true); campaign and workflow enrollment can also start
communications. Include the intended
notification behavior in the request. Use a read to identify an existing
record before updating or deleting it; never guess target IDs.
The CLI does not automatically retry mutations. If a write fails after submission or its outcome is unconfirmed, inspect the record or provider status before trying again. Keep the same idempotency key for the same logical mutation; do not create a fresh key to work around uncertainty. Report sends as accepted or scheduled unless the provider confirms delivery.
Treat financial, publishing, messaging, access-control, and deletion operations
as consequential: describe the operation first, show the exact intended
parameters, and never infer or reuse identifiers across sub-accounts. Future
operations not yet in list-operations require fresh approval, even for a read
or dry run.