When a form is submitted and a rep gets a Slack message three seconds later, a webhook made it happen. A webhook is a message one system sends to another the moment something happens — 'a form was submitted, here is the data' — rather than waiting to be asked. Understanding them is the difference between automation that is instant and automation that runs every fifteen minutes and misses things.

Polling versus pushing

Polling: your automation asks the form tool every few minutes 'anything new?' It is simple, it is late by up to the interval, and it can miss records or fetch duplicates. Pushing: the form tool sends each submission to a URL you gave it, as it happens. Instant, complete, and it needs the receiving end to be reliable.

What can go wrong

The receiving URL is down for a minute and the event is lost unless the sender retries. The same event is sent twice and creates a duplicate unless the receiver checks. The payload format changes without notice. The webhook is not authenticated and anyone who finds the URL can send fake data. Each has a standard fix: retries with a queue, idempotency keys, schema checks, signed payloads.

Questions for a vendor

Do you send webhooks, for which events, with what payload? Do you retry on failure, how many times, over how long? Do you sign the payload so we can verify it came from you? Is there a log of deliveries we can inspect? A vendor with good answers can be automated in real time; one without will always be polled.

The receiving side

Put the orchestrator behind the webhook URL, acknowledge immediately, queue the work, and process it with the same checks every time. A webhook that is received and acted on in seconds, reliably, is the foundation every speed-to-lead and lifecycle system stands on.