Webhooks explained with a form submission
What a webhook is, followed step by step through what happens when a visitor submits a form, and why webhooks are how systems tell each other things.
The short answer
A webhook is a message one system sends to another the moment something happens, so the second system does not have to keep asking. An API call is your site asking a provider for something; a webhook is a provider, or your own site, telling another system that an event occurred: a form was submitted, a payment succeeded, an order shipped, a subscription lapsed. The receiving system does something in response. It is the mechanism behind most business automation, and the easiest way to understand it is to follow one form submission from the visitor’s click to the sales follow-up. Two rules make webhooks safe: verify every one, because the receiving address is reachable by anyone and fake events are trivial to send, and record every one before processing it, so nothing is lost when a step is slow or down.
A form submission, step by step
| Step | What happens | Where |
|---|---|---|
| 1 | The visitor fills in the form and clicks send | Browser |
| 2 | The site’s function receives the submission, checks the anti-spam token, validates the fields and stores the entry | Serverless function on the hosting platform |
| 3 | The function sends the visitor a confirmation and the team a notification through the email service | API call to the email provider |
| 4 | The function posts the submission to a webhook address on the automation platform | Webhook, outgoing |
| 5 | The automation verifies the signature, records the event and acknowledges | Automation platform |
| 6 | The automation creates or updates the contact in the CRM, assigns the owner and starts the follow-up sequence | API calls from the automation |
| 7 | The CRM, on assignment, sends its own webhook to the messaging tool to notify the owner | Webhook, incoming to the messaging tool |
| 8 | Every step is logged; a failure at any step raises an alert | Logs and monitoring |
Building webhooks properly
- Verify the signature before anything else; reject anything that fails.
- Record the event with a unique identifier, then acknowledge quickly.
- Process idempotently: the same event delivered twice, which happens on retries, must not create two contacts or two orders.
- Do the work asynchronously where it is slow, so acknowledgement is not delayed.
- Log every event and outcome so a missing lead can be traced.
- Alert on failures and on silence: if a form that usually sends ten a day sends none, something is wrong.
- Keep the secret in the platform’s secret storage and rotate it if it is ever exposed.
Where webhooks show up
Payment confirmations, form submissions, order events from a store, calendar bookings, support tickets, repository pushes triggering a deployment, monitoring alerts, and almost every connection an automation platform makes. Once you can see the pattern, a business’s automations are a map of webhooks and the API calls they trigger, and the map is worth drawing.
What this means for you
Webhooks are how systems tell each other that something happened, and they power most of your automation. Every webhook must be verified, recorded before processing, handled so that duplicates do no harm, logged and monitored, with the secret kept in proper storage. Built that way, a form submission reliably becomes a contact, a notification and a follow-up; built carelessly, it becomes lost leads and fake events.
Frequently asked questions
What is the difference between a webhook and an API?
Direction. With an API your site makes a request and waits for the answer. With a webhook another system makes a request to an address you gave it, whenever something happens on their side: a payment succeeded, a form was submitted, an order shipped. Webhooks are how systems tell each other about events without constantly asking.
Are webhooks secure?
Only if verified. The address that receives a webhook is reachable by anyone, so a fake event could be sent to it: a forged payment confirmation, a bogus form entry. Providers sign their webhooks with a secret, and the receiving code must check the signature before acting. Any webhook receiver that does not verify is a hole.
What happens if our automation is down when a webhook arrives?
Good providers retry for a period, and a well-built receiver records every event before processing it so nothing is lost. The design rule is to accept the event quickly, store it, acknowledge it, and do the work afterwards, so a slow step or an outage downstream does not lose the event. Ask how your setup handles retries and failures; the answer tells you how it was built.
Sources
- Stripe Docs: Receive Stripe events in your webhook endpoint (accessed 2026-09-12)