Webhooks explained for marketers (no code required)
If you've set up any automation, you've met webhooks. They're simpler than they sound, and understanding them makes the difference between copying tutorials and building things.
The concept
Two ways for systems to talk:
Polling — asking repeatedly. "Any new leads? Any new leads?" Wasteful and delayed.
Webhooks — being told. The system sends a message the moment something happens. Immediate and efficient.
A webhook is just a URL that listens. Something happens over there; a message arrives at your URL.
What actually gets sent
A small package of data, usually JSON, describing what happened:
{
"name": "Sarah",
"email": "sarah@example.com",
"form": "contact-page",
"page": "/contact.html"
}
That's it. Field names and values.
The typical marketing setup
- Someone submits a form on your site
- The form sends that data to a webhook URL at Make.com or n8n
- That workflow adds them to your CRM, sends a notification, and triggers a follow-up
All within seconds, with nothing polling anything.
The three things that go wrong
1. A 200 response doesn't mean it worked.
This is the one that catches everyone, including me.
When your form posts to a webhook, the platform typically replies "received" straight away. Your website shows a success message. That confirms the webhook accepted the data — not that anything downstream ran.
I lost real time to this. Make had auto-disabled a scenario after consecutive errors. The webhook kept accepting submissions and returning success. My site kept showing visitors a green tick. Nothing ran, and the data queued invisibly.
Check the platform's execution log, not your success message.
2. Field names must match exactly.
Send email_address while the workflow expects email and you get an empty field, not an error. Case matters too.
Always run one real test submission and inspect what actually arrived.
3. Nothing retries by default.
If the receiving system is down when the webhook fires, the message is usually gone. Most platforms offer retry configuration — it's off unless you turn it on.
For anything that matters, enable retries and set a failure alert.
Security basics
A webhook URL is effectively a password. Anyone with it can send you data.
- Don't publish it. It'll end up in your public JavaScript if you're not careful — mine is, which is a deliberate trade-off for a simple contact form, but it means the workflow must validate what arrives.
- Validate incoming data before acting on it.
- Rotate the URL if it leaks.
- Use a secret or signature check where the platform supports it.
Where to start
Most form tools, CRMs and e-commerce platforms can send webhooks, usually under "integrations" or "developer" settings.
Simplest first project: form submission → webhook → email notification to yourself. Fifteen minutes, and it teaches you the whole shape.
Then check the execution log even when it appears to work. That habit will save you more time than anything else in this post.