What Is a Webhook? Explained for Business Owners (With CRM Examples)

Every automation conversation with a business owner eventually reaches the word “webhook”, usually in the sentence “we could just use a webhook for that”. Then the owner nods and later asks me what one actually is. Fair question. Here is the answer without the programmer’s vocabulary, and the four places I use them most in CRM setups.

The one-sentence version

A webhook is one system sending a message to another the moment something happens, with the details attached — “a form was just submitted, here is the name, email and phone” — and the receiving system acting on it immediately.

That is it. No schedule, no checking every five minutes, no human in the middle. The event happens; the message goes; the other system responds.

An everyday analogy

Think of a doorbell. An API is you walking to the door every few minutes to see if anyone is there (polling). A webhook is the bell: the visitor presses it, you hear it, you answer. The bell does not know what you will do — that is up to you — it just tells you, right now, that someone is there.

Webhook vs API

Most real integrations use both: the webhook says “something happened”, and if more information is needed the receiving system uses the API to look it up.

What a webhook actually contains

A webhook is a web request (usually a POST) to a URL, carrying a payload — a structured block of text, almost always JSON. For a form submission it looks roughly like this:

{
  "event": "form_submitted",
  "form": "Contact – Home page",
  "first_name": "Sarah",
  "email": "sarah@example.com",
  "phone": "+447700900123",
  "service": "Boiler repair",
  "utm_source": "google",
  "submitted_at": "2026-09-16T09:41:00Z"
}

The receiving system reads the fields it recognises and ignores the rest. “Mapping” — the word you will hear from anyone setting this up — just means telling the receiver which incoming field goes into which of its own fields.

Four ways I use webhooks in CRM setups

1. Website form → CRM. An Elementor form posts to a GoHighLevel inbound-webhook trigger; the workflow creates the contact and opportunity and sends the instant reply. No Zapier, no monthly task quota. The full walkthrough is in connecting WordPress forms to your CRM.
2. CRM → ad platforms. When a lead is marked won, the CRM sends a webhook (or uses the Conversions API) so Meta and Google learn which leads became customers — covered in the Meta Pixel and CAPI guide.
3. Payment → CRM. Stripe or WooCommerce tells the CRM an order was paid; the CRM tags the contact as a customer, stops the sales sequence and starts onboarding.
4. Chatbot → CRM. The website chatbot posts each conversation and captured lead to the CRM, so nothing lives only in a transcript. Part of every chatbot build.

Webhook or Zapier / Make?

If two systems both speak webhooks and the data needs no reshaping, a direct webhook is simpler, faster, free and has fewer things to break. Reach for Zapier or Make when you need to transform data (split a full name, reformat a phone number), branch on conditions, or fan one event out to several destinations — or when one side has no webhook support at all. A comparison of the two automation tools is coming in this series.

Where webhooks live in the tools you already use

You do not need to install anything; most business software already has a webhook setting, usually under “integrations”, “developers” or “advanced”.

The pattern is always the same: copy a URL from the receiver, paste it into the sender, choose which event fires it, and test with a real submission.

What goes wrong, and what to do about it

• The receiver was down for ten minutes. Webhooks are fire-and-forget unless the sender retries. Good platforms retry; many forms do not. Keep a backup — an email notification, or the form storing its own copy of every submission — so nothing is lost silently.
• A field was renamed. The form plugin updates, “phone” becomes “phone_number”, and the CRM stops receiving numbers. Test after every plugin update; a monthly test submission takes a minute.
• The URL leaked. Anyone with the URL can send fake data. Keep it out of public code and screenshots, and where the receiver supports a secret token or signature, use it.
• Duplicates. A retry after a slow response can deliver the same event twice. Receivers that match on email or a unique ID de-duplicate; a CRM “create or update contact” action handles it.
• Nobody knows it exists. Document every webhook: what sends it, where it goes, what fields it carries. The next person to touch the site will thank you.

How to test one in two minutes

Free request-inspection tools give you a temporary URL that displays anything sent to it. Point your form’s webhook at it, submit the form, and read the payload — you will see exactly which fields arrive and how they are named. Then point the form at the real destination and map the fields with confidence. I do this on every integration; it removes all the guessing.

Further reading: GoHighLevel Help Center · WooCommerce webhooks.

FAQ

Have two systems that should talk and don’t? Tell me which ones — most pairs can be connected with a webhook in an afternoon, and I will say so if they cannot.