What is a webhook?

What it is, in plain words

Think of a parcel you are waiting for. You can walk to the front door every twenty minutes to see if it has arrived. Or the courier can ring the bell when it gets there.

Walking to the door on a timer is called polling. The courier ringing the bell is a webhook.

In software terms: when something happens in one app (a form is submitted, a payment goes through, a file is uploaded), that app sends a short message to an address you gave it. The message says what happened and includes the details. Whatever sits at that address, usually your automation, wakes up and does its work.

Two terms you will hear around it:

• Webhook URL or endpoint: the address the message is sent to. It belongs to your automation platform or your server.
• Event: the thing that triggers the message, such as “new order” or “invoice paid”. Most apps let you pick which events to send.

A concrete example

Say a small business wants every new website enquiry in its CRM within a few minutes. There are two ways to build it.

With a webhook: the form tool is told, “whenever someone submits the form, send the details to this address”. The automation sits at that address. A visitor submits the form, the form tool sends the message within seconds, and the automation creates the CRM record. Nothing runs between enquiries.

With polling: the automation wakes up every few minutes, asks the form tool “anything new since last time?”, and handles whatever comes back. It works, but each enquiry waits for the next check, and every check that finds nothing still runs.

I run a job of the second kind. It replies to comments on social posts, and it checks for new comments every 20 minutes. The polling itself was fine. What went wrong was how much it looked at: for a while it only looked at the 12 newest posts, and because I publish several posts a day, that covered about a day and a half. In September, two comments arrived on a post that had slipped to 19th place. The job never looked there, so it never even tried to answer them. Nothing errored. I found them by hand and replied myself, then changed the job to look at every post from the last seven days.

That is the trade-off in one story. Polling only sees what it goes looking for. A webhook, where the app offers one for that event, is sent for each event as it happens, but you then depend on the message actually arriving.

My publishing job has a small polling step too: after it pushes a new page, it checks every 30 seconds, for up to ten minutes, whether the page is live before telling search engines about it. Polling is not wrong. It is a choice with a delay built in.

Why it matters when you hire someone

You will not configure webhooks yourself. But three things about them decide whether your automation is reliable, and a buyer who does not ask about them usually finds out later.

1. Something has to be listening all the time. A webhook is only useful if the address is reachable the moment the message arrives. On a hosted platform that is normally taken care of. On a self-hosted server or someone’s laptop, it is not: if the machine is asleep or restarting, the message arrives at a closed door.

2. A missed message may not come back. Some apps retry a failed delivery a few times; some do not. If yours does not, an enquiry or an order can vanish without an error anywhere. This is the webhook version of the silent failure that the acceptance checklist for unattended automations is built to catch.

3. The same message can arrive twice. Retries mean duplicates are possible. A well-built automation recognises a message it has already handled and does nothing the second time. A careless one creates two CRM records, sends two emails or charges twice.

There is also an ownership point. The webhook is registered inside the sending app’s account. If that account is the freelancer’s, or the webhook points to the freelancer’s server, your automation stops when their access or subscription does.

What to ask the freelancer

Paste these into your first message, or into the “Trigger” and “Failure behaviour” fields of the workflow automation brief:

The last question matters more than it looks. A webhook that silently stops firing and a polling job that silently looks in the wrong place produce the same symptom: nothing happens, and nothing tells you. (I lost a night of scheduled posts that way; the field note on scheduled jobs and sleep mode shows how quiet it looks.) Ask for an alert that notices when the usual activity has gone quiet, not only when something crashes.

A good answer is short and specific: where the address lives, what the sending app does on failure, how duplicates are recognised, and what alerts you when things go quiet.