What is a webhook?

The alternative is polling, which means asking every minute whether anything changed. Wasteful, and always at least a minute behind.

A webhook reverses that. Something happens, a message arrives, and your system reacts within a second or two.

Delivery is where the design questions live. What happens when your endpoint is down, how many times it retries, and whether anything is lost.

Duplicates are normal rather than exceptional. A message whose acknowledgement went missing gets sent again, which is why receivers need to handle repeats.

Ordering is the other assumption worth dropping. Two events fired a second apart can arrive in either order, and code written to expect the sequence breaks on a busy morning.

Say your online booking tool sends a webhook whenever an appointment is created, and you've pointed it at a small script that texts the technician. At 10:04:07 a customer books. One second later the tool sends a POST to your address with a short message. It holds the event name "appointment.created", an event ID of evt_48121, the time and the customer's number. Your script answers "200 OK" within a second, then sends the text.

The order of those last two steps matters. Senders usually wait only a few seconds for your reply. Suppose your script sends the text first and the texting service is slow. The sender gives up, marks the delivery failed and tries again a minute later. Your technician gets the same job twice. So you acknowledge first and do the work second, and you store evt_48121 so a repeat with that ID gets ignored.

Most senders keep a delivery log in their settings, listing each attempt with a status code and a time. Look at yours once a month. A healthy log is a column of 200s. Seeing a few 500s or timeouts that succeeded on retry is fine. A run of failures with no later success is a lost record, and it gives you the date to go looking.

Ask the sender two things. For how long do you keep retrying, a few minutes or a few days? Can I replay a failed event by hand from the log? That second feature is what saves you after a weekend outage.

On security, the sender should sign each message, commonly with a method called HMAC-SHA256 and a secret only the two of you share. Your side recomputes the signature and rejects anything that doesn't match. Without that check, anyone who learns the address can post a fake booking to it.

Webhooks are native to GreetKeeper. It sends one JSON POST per event to a URL you set, for a completed call, a booking, a message taken and a transfer, signed with an HMAC-SHA256 header and retried with backoff on a failed delivery.

The call itself never depends on the delivery. Records stay with us whether or not the message reached your endpoint.

In Zapier you catch the same webhook with Webhooks by Zapier, which needs a paid Zapier plan. That hop has its own retry behavior worth understanding before you rely on it for bookings.