WhatsApp Webhooks Explained for People Who Don't Write Code

Imagine you've ordered a sofa. You could phone the shop every hour asking if it's ready. Or you could give them your number and ask them to call when it is. A webhook is the second option, for software.

That's genuinely all it is. If your developer says 'we'll need a webhook for that', they mean: give WhatsApp an address on your system, and WhatsApp will send a message to that address whenever something interesting happens.

What triggers one

• A customer sends you a message or taps a button.
• A message you sent changes status, for example from sent to delivered to read.
• A message fails to deliver.
• On the official route, a template's approval status changes.

Without a webhook, your software can send messages but it is deaf. It would have no idea a customer replied 'Yes, confirm my appointment' until someone opened a phone and looked. This is why almost every reminder or confirmation workflow that expects an answer needs one.

The doorbell and the front door

Here's how the pieces line up. You sign up with an API provider. You give them a web address, called the webhook URL, that belongs to your system. When an event occurs, their server makes a small request to that address, carrying the details: who, what, when. Your system receives it and decides what to do.

What it does is up to you. It might save the reply in a database, mark an invoice as 'customer responded', alert a staff member, or send an automatic answer.

The API is how you talk to WhatsApp. The webhook is how WhatsApp talks back.

A worked example

Take a physiotherapy clinic that sends appointment reminders. At six in the evening, the system sends 'Your session is tomorrow at 10. Reply 1 to confirm, 2 to reschedule.' A patient replies '1'.

1. 1WhatsApp receives the reply.
2. 2WhatsApp calls the clinic's webhook address with the patient's number and the text '1'.
3. 3The clinic's software matches the number to tomorrow's booking.
4. 4It marks the booking as confirmed and removes it from the 'call these people' list.
5. 5Nobody at reception had to read a single chat.

That is the entire value of webhooks: work that used to wait for a human glance now happens by itself. For a business with a few hundred bookings a month, that can add up to real hours back each week.

What to ask your developer

You don't need to write any of this, but you should know what to ask. These are fair questions to put to whoever builds it.

• Is the webhook address on HTTPS, and does it reject requests that aren't really from our provider?
• What happens if our server is down for an hour? Does the provider retry, and do we get duplicates?
• Can the same event arrive twice, and does our code cope with that?
• Where do we see a log of what came in, in case something looks wrong?

Webhooks in a gateway

With WA Getway, webhooks are one of the built-in features. You point them at your own system, and incoming activity can be pushed there. If you aren't a developer, you can still use the dashboard, auto-replies and inbox without touching webhooks at all. They only matter once you connect WhatsApp to other software.

Where this fits in the bigger picture

Two ways it goes wrong

The first is silence. The webhook address changes, a certificate expires, or the server restarts at the wrong moment, and events stop arriving. Nothing crashes. You just stop hearing about replies. A simple fix is a daily check that compares messages sent with statuses received, and raises a flag if the gap looks odd.

The second is noise. Every status change fires an event, so a busy day can mean thousands of small requests. That is fine if your receiver answers quickly and does heavy work later in the background. It is not fine if every event triggers a slow database search while the provider waits. Ask your developer to keep the receiver light.

Webhooks are what turn delivery receipts into something useful, which we explain in sent, delivered and read. They also pair naturally with sending from your own site, covered in sending WhatsApp messages from your website.

If you have a system in mind and aren't sure whether a webhook is needed, describe it to us. Most of the time the answer comes down to one question: does your software need to know what happened after the message left?