What is the difference between a webhook and an API?

An API waits for your request and answers it. A webhook sends data to you on its own when an event occurs. In practice they work together: a webhook says that something happened, and your system can call the API for more details.

They can be, if the receiver does its part. Use an HTTPS endpoint, verify the signature the sender attaches to each payload, and reject requests that fail the check. Keep the shared secret on the server and replace it if it leaks.

What happens if my webhook endpoint is down?

Most senders retry failed deliveries for a while, and some switch the webhook off after repeated failures. Because retries can deliver the same event more than once, store event IDs and skip the ones you have already processed.

Does intoCHAT support webhooks?

No. intoCHAT does not send webhooks and has no Zapier or Make integration. Each new lead triggers an email alert to the owner and up to 5 more addresses, and you can export leads as CSV from the leads table.

Webhook

Last updated: October 6, 2026

What a webhook is

A webhook is sometimes called an HTTP callback or a reverse API. With a regular API call, your program asks another system for data. With a webhook, you register a URL once, choose the events you care about, and the other system calls that URL whenever one of them occurs. The message is usually a POST request with a JSON body that describes the event.

The alternative is polling: checking an API every few minutes for changes. Polling wastes requests when nothing has happened and delays updates when something has. Webhooks avoid both.

How it works

A webhook has a sender and a receiver:

The receiver creates an endpoint, a URL on its own server that accepts incoming requests over HTTPS.
In the sender's settings, the receiver registers that URL and picks the events to subscribe to.
When an event happens, the sender posts a JSON payload with the event type and its data to the URL.
The receiver checks that the request is genuine, replies quickly with a 2xx status code and then processes the data. If no success reply arrives, the sender typically tries again later.

Example

An online shop wants its warehouse software to know about every new order. Instead of the warehouse software asking the shop every minute, the shop sends a webhook to the warehouse software's endpoint whenever an order is placed. The payload contains the order number, items and shipping address, so packing can start within seconds.

Good practice for receiving webhooks

A webhook endpoint is a public URL, so treat every incoming request with care:

Verify the signature. Many senders sign each payload with a shared secret, often using HMAC, so you can confirm the request came from them and was not changed on the way.
Use HTTPS, so payloads, which may contain personal data, are encrypted in transit.
Respond fast. Return a 2xx status right away and do slow work in the background, or the sender may treat the delivery as failed.
Expect duplicates. Retries can deliver the same event twice, so use the event ID to process each event only once. This property is called idempotency.

Why it matters for business chatbots

Webhooks connect a chatbot to the rest of a business without anyone watching a dashboard. A chatbot platform can send a webhook when a conversation ends or a lead is captured, so a CRM, a spreadsheet or an automation tool picks it up immediately. When you compare chatbot tools, check which events they can send and whether the payloads are signed.

What intoCHAT does instead

intoCHAT does not send webhooks and has no Zapier or Make integration. New leads reach you in two ways: an email alert for every new lead, sent to the account owner and up to 5 more addresses, and the leads table, where you can filter leads, open the conversation behind each one and export them as CSV for your CRM or mailing tool.

intoCHAT's custom API actions work differently from webhooks. The agent calls your HTTP API during a chat when the conversation needs it, for example to look up a price or check availability, not automatically on a fixed event. They bring live data into answers; they are not a way to forward every lead to another system.