The lead notification email arrives. Someone copies the name into the CRM, then the email address, then pastes the enquiry into the notes field. On a busy Monday that happens fifteen times, and on at least one of them the email address gets a typo and the follow-up bounces.
A webhook removes that step. When the website assistant has a finished enquiry, it sends the details straight to another system, and the record appears in your CRM without anybody touching a keyboard.
This guide explains what a chatbot webhook to your CRM actually does, the ways to connect one, and how to test it so you trust it.
A webhook, without the jargon
A webhook is a message one system sends to another automatically when something happens. You give the sender an address, a URL, and it posts information to that address each time the event occurs.
Think of it as the assistant filling in a form on your CRM's behalf. The webhook URL is where the form goes. The data inside is what the assistant learned in the conversation.
In SpideyChat, sending a webhook is one of the actions you can switch on per assistant. Like all actions, it is off by default. Once you add a webhook URL and turn the action on, the assistant sends a JSON POST to that URL when a conversation produces something worth passing on, such as a qualified enquiry.
What actually gets sent
Each send is a small bundle of structured data. The shape looks like this (the values here are made up):
{
"event": "qualified_lead",
"botId": "your-assistant-id",
"conversationId": "a-conversation-id",
"variables": { "name": "Priya", "email": "priya@example.com" },
"data": { "service": "loft conversion", "postcode": "LS6" },
"at": "2026-09-14T19:42:10.000Z"
}
In plain terms: event is a short name for what happened, variables holds details captured in the conversation, data carries any extra detail the assistant includes, and at is the time. The conversation ID lets you find the full transcript in your inbox later.
You do not need to read JSON to use this. Your automation tool or CRM will show these as fields you can pick from a list.
Three ways to connect
Which route suits you depends on your CRM and how comfortable you are with setup screens.
| Route | Best for | What you do | Trade-off |
|---|---|---|---|
| Zapier | Most small businesses with a mainstream CRM | Create a zap with a webhook trigger, paste its URL into the assistant, map fields to your CRM | Easiest to set up; the automation tool has its own subscription |
| Make | People who want branching logic, such as different pipelines per service | Create a scenario with a custom webhook module, then add CRM steps | More flexible, slightly steeper learning curve |
| Direct to your CRM or system | CRMs or in-house systems that accept incoming webhooks | Paste the CRM's inbound webhook URL and set up field mapping on the CRM side | No middle tool, but the CRM must understand the format |
For most businesses the automation tool route is the practical one. It also lets you add extra steps to the same trigger, such as posting to a Slack channel or adding a row to a spreadsheet. See the integrations page for how these fit together.
Setting it up, step by step
These steps follow the Zapier or Make route. The idea is identical for both.
- Create a new automation and choose a webhook trigger (Zapier calls it catching a hook; Make calls it a custom webhook).
- Copy the webhook URL it gives you.
- Paste the URL into your assistant's webhook setting and switch on the send webhook action.
- Tell the assistant when to send. In its instructions, write something like: "Send a qualified_lead event once you have the visitor's name, email and the service they want. Do not send for general questions."
- Send a test enquiry by chatting with the assistant as a pretend customer and giving it made-up details.
- Go back to the automation tool and confirm the data arrived. Most tools show the fields they received.
- Add the CRM step and map each field: name to contact name, email to email, service to a custom field or note.
- Run one more test and open the CRM to check the contact looks right.
- Turn the automation on.
Step four is the one people skip. Without a clear instruction, you may get a record for someone who only asked about parking.
Testing like someone who has been caught out before
A webhook that works once in testing can still fail quietly later. A few habits help.
- Test with awkward details. An apostrophe in a surname, a very long enquiry, a visitor who gives an email but no name. See what reaches the CRM.
- Check duplicates. A returning visitor may produce a second record. Decide whether your CRM should merge by email.
- Keep the email notification on for the first month. Compare it with the CRM weekly. If a lead is in your inbox but not in the CRM, something broke.
- Know where to look. Your automation tool keeps a history of runs, including failures. Bookmark it.
For more on keeping the data itself tidy, how chatbots feed your CRM with clean lead data covers field choices and qualification.
A quick check on whether it is worth doing
Here is a rough example to adapt. Say you get 12 chat leads a week and each takes about 4 minutes to copy into the CRM and double-check. That is 48 minutes a week, or around 40 hours a year, plus the cost of the occasional mistyped email address.
Setting up the webhook might take an hour or two the first time. If your numbers look anything like these, it pays back within a month. If you get two leads a week, the email notification alone may be enough, and that is a perfectly sensible choice.
What to do next
Decide which route fits your CRM using the table above. Create the webhook trigger in your automation tool, paste the URL into your assistant, and write the one-sentence instruction about when to send. Then run a fake enquiry with an awkward surname and check what arrives.
The docs show where the webhook setting lives, and the pricing page shows what each plan includes. If your next question is what to do once the lead lands, following up on chatbot leads is the natural next read.