Open the settings of any form tool and there is a section called webhooks, usually containing a box asking for a URL and nothing that explains why you would want one. Most people close it again.
That is a shame, because a webhook is the mechanism that connects a form to everything else you use, and the concept underneath it is genuinely simple. The obscurity is a documentation failure rather than a complexity one.
This is what it is, what it is for, and what to do about it if you do not write code, which most people reading a form tool's settings do not.
What a webhook actually is
When somebody submits your form, your form tool can send a message to another system saying this just happened, here is what was in it. That message is the webhook. The URL you paste in the box is the address it gets sent to.
The name is unhelpful and there is no better one in common use. Think of it as an automatic notification aimed at software rather than at a person. You already have notifications aimed at people, which is the email that arrives when a form is submitted. A webhook is the same event, addressed differently.
That is the whole concept. Everything else is detail about what sits at the other end and what it does when the message arrives.
A webhook is the same notification you already get by email, addressed to software instead of to a person.
Why not just use email
Email notifications work and they have a ceiling. They land in an inbox, where they require a person to read them and do something, and the doing something is usually retyping information into another system.
A webhook removes the person from that loop. The enquiry arrives in your CRM already, the customer is added to your mailing list already, the job appears on your board already. Nobody copies anything, which means nobody makes a typing mistake, and it happens in seconds rather than whenever somebody checks their email.
For a business doing five enquiries a week this is a convenience. For one doing fifty, it is the difference between a person spending an hour a day on data entry and that hour going somewhere useful.
You probably do not need to build anything
The assumption that a webhook requires a developer comes from the fact that the documentation is written for one. In practice, most small businesses never send a webhook to something they built. They send it to an automation tool.
Zapier, Make and their equivalents exist specifically to sit at the other end of a webhook and then do something with it, configured by clicking rather than coding. You paste their URL into your form tool, and then you tell them what to do when a submission arrives.
Many tools also have a direct integration, which is a webhook with the configuration already done for you. If your CRM appears in your form tool's integration list, use that rather than building it yourself, because somebody has already handled the parts that are fiddly.
What people actually connect
The uses that come up repeatedly in small businesses are unglamorous and each saves a specific recurring annoyance.
- Enquiries into a CRM or a shared spreadsheet, so nothing depends on one person's inbox.
- New customers onto a mailing list, with the consent answer carried across rather than assumed.
- Bookings into a calendar, so the diary is correct without anybody transcribing dates.
- A message into a team chat, which is a better shared inbox than email for anything more than one person handles.
- A task created on whatever board the work actually gets tracked on.
- An accounting entry when a form takes a payment, which saves reconciling two lists at month end.
Start with one connection
The common mistake is designing an entire automated pipeline before anything is working. Six steps, four tools, conditional branches, and then a week later nobody can tell why a particular enquiry did not appear.
Connect one thing. Get submissions into the one place where they most need to be and where somebody is currently retyping them. Live with it for a fortnight, confirm it is reliable, and then add the second.
Automation failures are quiet by nature, which is what makes them expensive. A chain built one link at a time, with each link watched for a while, is much more likely to still be working in six months than one assembled in an afternoon.
The signature, and why it matters
One security point that is worth understanding even if somebody else implements it. A webhook is delivered to a URL, and a URL can be sent things by anybody who knows it.
That means the system receiving your webhook cannot assume a message came from your form tool just because it arrived. Anybody could send it a made-up submission, and if that submission creates a customer record or triggers a payment, that is a real problem rather than a theoretical one.
The fix is a signature, which is a code sent with each message proving it came from the right sender. Reputable form tools send one. If you are sending webhooks to something built for you, ask whether the signature is being checked, because it frequently is not.
Things will fail, and that is normal
Webhooks fail regularly and for boring reasons. The receiving system is briefly down, a service is being updated, a network hiccup happens. This is expected and it is why any decent tool retries.
What matters is whether you find out. A webhook that failed and was never retried means an enquiry that exists in your form tool and nowhere else, and you will discover it when a customer asks why nobody got back to them.
Look for two things in whatever tool you use: automatic retries, and a log you can look at showing what was sent and whether it succeeded. The log is the thing you will want at the exact moment something has gone wrong, and its absence turns a five minute check into an afternoon.
Do not automate the judgement
There is a limit worth respecting. Automation is excellent at moving information and poor at deciding what it means.
Getting an enquiry into your CRM automatically is unambiguously good. Automatically assigning it, scoring it, and starting a sequence of emails based on what somebody typed into a form is where it goes wrong, because the form does not know that this particular enquiry is from an existing customer with a complaint.
A reasonable line is to automate everything up to the point where a person would exercise judgement, and stop there. The person then has the information in front of them rather than having to find it, which is most of the benefit with none of the embarrassment.
What the message looks like
If you ever need to look at one, a webhook message is a block of text in a structured format called JSON, which looks like a list of labels and values with a lot of brackets. It is meant to be readable by software and it is legible enough to a person who needs to check something.
The useful skill is not reading it fluently. It is knowing that if a connection is not working, looking at the message will usually tell you why, because the problem is nearly always that a field is named something other than what the receiving system expected.
Automation tools show you this and let you map the fields by picking from a list. That mapping step is where most setup problems live, and it is worth doing slowly rather than accepting the defaults.
Testing properly
Test with a real submission that looks like a real enquiry, not with the word test typed into every field. Half the problems in an automated chain only appear with realistic data.
A name with an apostrophe in it. An address over several lines. A free text answer containing a line break. An optional question left blank. Each of these breaks something somewhere at least once in every setup, and finding out with a test submission is much better than finding out with a customer.
Then test the branch you did not think about. If your form has conditional questions, submit a path where the fields are different, because a mapping that assumes a field is always present will fail silently when it is not.
Keep a note of what is connected
Six months after setting this up, nobody remembers what is wired to what. That is fine until something needs changing, at which point a renamed question quietly breaks a connection nobody knew existed.
Keep a short document listing each form, what it is connected to, and what happens at the other end. Five lines per connection. It takes fifteen minutes and it is the thing you will be grateful for when a form needs editing.
The specific trap is renaming a question. Downstream systems usually reference fields by name, so a tidy-up in the form editor can break an automation without any error appearing anywhere either person is looking.
Order of arrival is not guaranteed
One behaviour that catches people out when a chain gets longer. If two submissions arrive within a few seconds of each other, there is no promise they will be processed in that order, and if a webhook is retried it may arrive after a later one.
For most small business uses this never matters, because each enquiry is independent. It starts to matter when one step depends on another having completed, such as adding somebody to a list and then immediately sending them something based on what the list contains.
The general guidance is to keep each connection self-contained, carrying everything it needs, rather than relying on something that happened a moment earlier. That is also easier to debug, because each message can be understood on its own.
What to do when it breaks in six months
Automations fail eventually, and almost always because something at one end changed. A field was renamed, a service updated its interface, an account's access expired, or somebody rebuilt the form.
The diagnosis order is nearly always the same. Check the form tool's delivery log first, which tells you whether the message was sent and what the other end said. If it was sent and rejected, the problem is at the receiving end. If it was never sent, the problem is a trigger or a setting on your side.
Between those two checks and the note of what is connected to what, most breakages are a ten-minute fix. Without them it is an afternoon of clicking through settings screens hoping to recognise something, which is how a broken automation ends up staying broken.
Where to start
Pick the one place where somebody currently retypes information from an enquiry into another system. That is the connection worth making first, because the benefit is measurable in minutes per week.
If your form tool has a direct integration with that system, use it. If not, use an automation tool as the middle step. Either way, send one real submission through, check it arrived correctly, and then leave it alone for a fortnight before building anything else.
The businesses that get the most out of this are not the ones with the most elaborate setups. They are the ones with three connections that have worked without attention for a year.