What is a webhook and how does it work in business workflows

Short answer

A webhook is a notification one system sends to another automatically when an event happens. Technically, it is an HTTP request sent to a pre-agreed address (URL), carrying the event's data: "a new lead was created, here is the name, here is the number". In business workflows, webhooks keep systems informed: the CRM no longer needs to ask "anything new?" every five minutes — the data arrives the moment the event happens. A reliable webhook needs three things: the receiver acknowledging quickly, failed deliveries being retried, and the sender's identity being verified.

In plain terms: don't call us, we'll call you

There are two ways for one system to learn about a change in another. The first is asking: the CRM asks the chat platform "any new leads?" every five minutes. Usually the answer is "no", yet the requests keep going, and a lead can be up to five minutes late. The second is a webhook: you tell the chat platform "when there's a new lead, notify this address". The notification arrives as soon as the event happens, with no empty requests.

An everyday comparison: instead of going to the post office every day to ask whether a parcel has arrived, you get a text when it does.

The four parts of a webhook

1. 1EventWhat happened: "lead.created", "call.completed", "order.paid".
2. 2PayloadThe event's details, usually in JSON: who, what, when.
3. 3EndpointThe receiving system's URL — where the notification is sent.
4. 4Signature or secretSo the receiver can check the notification really came from the expected sender.

Webhook versus API: the difference

With an API you ask: "what is this order's status?" — and get an answer. With a webhook the system tells you: "the order's status changed". You call an API when you need to; a webhook arrives when the event happens. In real integrations the two work together: the webhook says "something changed", and the receiving system asks for the full details through the API if it needs them.

Examples in business workflows

• A number is written in chat → webhook → a lead is created in the CRM and a task goes to a manager.
• An AI call ends → webhook → the call outcome and summary are written to the customer record.
• A lead's status becomes "won" → webhook → the accounting system starts preparing an invoice.
• A payment goes through → webhook → the order status changes and a confirmation goes to the customer.
• A customer asks something not in the knowledge base → webhook → a notification to the person responsible.

Reliability: webhooks can get lost

The biggest risk with webhooks is silent failure: the sender sends the notification, the receiving system is down at that moment, the lead lands nowhere and nobody knows. Rules for a reliable webhook:

• The receiver acknowledges the notification quickly (usually with a 2xx response) and does the heavy work later, in a queue.
• The sender retries a failed delivery at set intervals.
• The receiver is ready for the same notification to arrive twice — a repeat must not create a duplicate.
• Events can arrive out of order — "status changed" may come before "created".
• Failed deliveries are visible in a log, and someone looks at them.

Security

A webhook address is open on the internet, so anyone can send requests to it. To protect it: use HTTPS only, verify the sender's signature or secret, put only the data you need into the notification (do not send the full conversation if it is not needed), and do not keep the address in code or in an open document. If personal data is transmitted, that must also follow the company's data rules.

What to ask when setting up a webhook

• Which events are sent, and what does a sample payload look like for each?
• How many times, and at what intervals, is a failed delivery retried?
• How is the sender's authenticity verified?
• Where is the delivery log, and who can see it?
• Is there a separate address for testing, and can test events be sent?

How to write these questions into an integration document is shown in the API integration requirements document.

Webhooks without a developer

Receiving a webhook does not always need custom code. Integration platforms (iPaaS) can receive a webhook, pass the data to another system, transform fields and apply simple conditions. For small and mid-sized companies this is often the fastest route. But bear two things in mind: the middleware also processes the data — check where personal data is stored — and it has failures of its own, so failed deliveries must be monitored there too. For critical flows, a direct and tested integration is often more reliable.

An illustrative example

This is an illustrative example. A renovation company passes leads from its chat platform to the CRM by webhook. One Sunday the CRM server is updated and is down for two hours. The sender did not retry — the leads from those two hours were lost and found by chance on Monday.

The fix: a retry rule on the sending side, and a check on the receiving side so the same lead is not created twice. A notification to IT was set up for failed deliveries.

Common mistakes

• Treating a webhook as "set and forget" — nobody looks at failed deliveries.
• Not being ready for retries — the same lead gets created twice.
• An open address with no signature check.
• Sending unnecessary data, especially personal data.
• Going live without testing with a test event.

Limitations

A webhook only reports an event; it does not decide what the receiving system will do. At very high volumes, webhooks can overload the receiver, so a queue is needed. Some older systems cannot receive webhooks at all — they need an intermediary service or file-based transfer.

Webhooks in Vexvon

Vexvon can send events such as a new lead, a completed call and a status change to the company's own system by webhook at the moment they happen. In the other direction, a company offers its own API to the AI as a tool, and the bot calls it — for example, on "where is my order?". There is a ready-made connection for passing leads to Bitrix24. More on integrations.

Next step

Find one piece of information currently copied by hand between your systems — leads from chat to the CRM, say. Write the event, the data and the receiving address for it on one page. A chatbot's API and webhook architecture is covered in chatbot API and webhook integration, and the general integration layers in enterprise AI integration. More articles are in the enterprise integration section, and we can plan your webhooks together during a demo.