HookGet Open dashboard

GoHighLevel → HookGet

GoHighLevel calls HookGet; the request is verified at the door and becomes normalised events on the same pipeline as everything else you deliver.

In short

  • Verifies both GHL schemes: current Ed25519 (x-ghl-signature) and legacy RSA (x-wh-signature), over the raw bytes.
  • Contacts become lead.* events, opportunities become deal.*, with the pipeline stage as an attribute.
  • Opportunity values arrive in whole currency units and are converted to cents, so CRM money and Stripe money add up.
  • Unknown GHL event types pass through under their own names.

What it produces

GoHighLevel sendsBecomesData
ContactCreate / ContactDeletelead.created / lead.deletedlead_source
InboundMessage / OutboundMessagelead.replied / lead.contacted—
AppointmentCreate / Update / Deletelead.booked / .appointment_updated / .appointment_cancelled—
OpportunityCreatedeal.createdamount_cents, pipeline_stage
OpportunityStageUpdate / StatusUpdatedeal.stage_changed / deal.status_changedpipeline_stage, status
OrderCreate / InvoicePaidpayment.succeeded / invoice.paidamount_cents

Set up

curl -X POST https://api.hookget.com/v1/sources \
  -H "authorization: Bearer $HOOKGET_KEY" \
  -d '{"provider":"gohighlevel","secret":"<GHL public key PEM>"}'
# → in GHL, point the webhook at the returned ingest path
How an inbound webhook is verified before it enters A provider sends a signed request. HookGet verifies the signature or token and deduplicates on the provider's delivery id before the event exists. A request that fails verification is refused with a 401 and never enters the pipeline. A verified event flows into the same pipeline as any other: retries, timeline, replay. The provider GitHub, Stripe, 13 more Verified at the door signature or token · dedupe The same pipeline retries · timeline · replay Refused bad signature → 401, nothing enters
Verification happens before the event exists, so a forged request is refused at the door — it is never stored, never retried, never seen again. Redeliveries are deduplicated on the provider’s own delivery id.

Stated plainly

GoHighLevel signs with one key pair for all of its customers. Verification therefore proves the payload came from GoHighLevel and was not modified — it does not prove which GHL account sent it. If that distinction matters, filter on the location_id attribute, which is the payload’s own statement of the sub-account.

Questions

Which signature scheme should I expect?

During GHL's transition both headers can arrive on one request. The connector prefers Ed25519 when your stored key is an Ed25519 key, verifies RSA when it is an RSA key, and refuses when the key does not match the scheme sent — misconfiguration fails loudly.

How do lead events relate to payments?

The contact id rides as the entity and correlation id. When a Stripe source is also connected, a lead's journey and its payment share the pipeline — filter both into the same destination and join on your side.