Two directions
GoHighLevel can send a webhook from any workflow step to a URL you control, and it can receive webhooks that create or update contacts through an inbound webhook trigger. Most integrations use both: a workflow sends data out to a service that does something the platform can't, and the service writes the result back.
Outbound from a workflow
The "Webhook" action in a workflow posts JSON to your endpoint. Include only what the service needs: contact ID, the two or three fields involved, and the event name. Big payloads with every field make debugging painful and leak data the service shouldn't hold. Add a custom header with a shared secret so the receiver can verify the call came from your account.
Receiving safely
Our receivers, usually a serverless function, do four things in order: verify the secret and reject anything else; extract an event ID (or build one from contact ID plus event name plus timestamp) and ignore duplicates; respond with a 200 immediately; then do the actual work in the background. Responding fast matters because the platform will retry a slow endpoint, and now you have the same event twice.
Design every action so that running it twice produces the same result as running it once. Updating a field is idempotent. Appending a note is not, unless you check whether the note already exists.
Inbound into GoHighLevel
An inbound webhook trigger gives you a URL; anything that posts JSON to it can start a workflow, and the workflow maps the payload onto contact fields. We keep the field mapping in one place, the workflow itself, with a naming table beside it in the account's documentation. Website forms on other platforms, partner systems and our own services all post to these triggers.
Errors and retries
Services fail. Ours catch every error, log it with the event ID, and post a short message to a monitored channel, following the same approach as our automation stack rules. Transient failures (a timeout calling a third-party API) are retried with backoff. Permanent failures (a malformed payload) are logged and skipped, never retried forever. The team learns about problems from the alert, not from a customer.
Log to the timeline
Whatever a service does, it writes a one-line note to the contact: "Quote calculated: $4,200 (v3 pricing). Sent to rep." That note is what makes the integration debuggable by a non-developer. When something looks wrong, the account manager opens the contact and sees exactly what happened and when.
Key takeaways
- Outbound webhooks from workflows carry the contact and any custom values you choose; keep the payload small and explicit.
- Every receiver checks a shared secret, de-duplicates by event ID and responds fast, doing the real work asynchronously.
- Inbound webhooks let outside systems create or update contacts; map fields once, in one place.
- Expect retries. Design every action so running it twice is harmless.
- Write a note to the contact for anything a service does, so the team can see it without opening code.