Webhook, the Glue Behind Most Chatbot Integrations

A webhook is an automatic HTTP request that one system sends to a URL you control the moment something happens. Instead of your software repeatedly asking "has anything changed yet", the other system pushes the event to you as it occurs: a call ended, a form was submitted, a payment cleared, a conversation finished.

Why it matters when you are buying or building

Webhooks are how a chatbot stops being an island. The bot handles the conversation, then a webhook carries what it learned into the systems that actually run the business. In practice almost every integration I build for a client is a webhook on one end and either an automation platform or a small serverless function on the other.

Two directions are worth keeping straight. Outbound webhooks fire from the chat or voice platform when an event happens, typically at the end of a conversation, and carry the transcript, collected fields and outcome. Inbound webhooks are URLs the platform gives you so that an outside system can start or influence a conversation. Function calling is the third relative: a request made mid-conversation whose response the model reads and reacts to. Webhooks are usually fire and forget, tools are request and response, and confusing the two is why some builds feel laggy for no reason.

A production example

The missed-call text-back flows I sell to contractors are pure webhook plumbing. A call comes into the business number and goes unanswered, the telephony provider fires a webhook with the caller's number and the call status, and an automation sends an SMS back within seconds asking how the business can help. That is it. No model required for the trigger, though one usually handles the reply thread afterwards. It is the single highest return automation I install for home-service clients, because a contractor on a roof misses calls all day and those callers dial the next result instead. The full build is in my missed-call text-back guide.

What to check before you rely on one

• Retries. If your endpoint is down for thirty seconds, does the sender retry or is the event gone?
• Ordering. Events can arrive out of order. Do not assume the "ended" event lands after the "started" one.
• Duplicates. Assume a webhook can fire twice and make your handler safe to run twice. Duplicate SMS to a customer looks careless.
• Verification. Use whatever signing secret the sender offers, and reject unsigned requests. A public URL that triggers texts is a public URL that strangers can trigger.
• Timeouts. Acknowledge fast, then do the slow work in the background.

If you are wiring this without writing code, an automation platform like Make will handle most of it for you.