How it works
There are two ways to learn that something has changed in another app. You can keep asking, which is called polling: any new orders yet? Or the other app can tell you. A webhook is the second way. You give the app a URL, and whenever the event occurs, such as a payment, a form entry or a new subscriber, it sends an HTTP request to that URL with the details.
The receiving end is called an endpoint. In an automation tool, a webhook trigger gives you a URL to paste into the sending app, and each incoming message starts a workflow. The message body, usually JSON, carries the event data. Because the URL is public, anyone who knows it could send a fake message, so careful senders sign each message and expect you to verify the signature before you act on it.
Creators meet webhooks when they connect a checkout, a community platform or a form to their own automations: grant course access when a payment succeeds, add a buyer to a list, post a welcome message. Webhooks are fast and efficient, and they come with habits worth learning early. Answer quickly, expect the same event to arrive twice now and then, and do not assume that events arrive in order.
A worked example
A creator wants buyers added to a members list the moment a payment succeeds.
- Create a webhook trigger in the automation tool and copy its URL.
- Paste the URL into the payment provider's webhook settings and choose the payment succeeded event.
- On each sale the provider sends the buyer's details to the URL, and the workflow adds the buyer to the list.
- The workflow checks the message signature first and records each event ID, so that a repeated delivery does not add the buyer twice.
An illustration, not a real account. Any numbers in it are made up to show the method, and are not benchmarks.
Common mistakes
- Trusting any request that arrives. Verify the sender's signature, or anyone with the URL can trigger your workflow.
- Assuming each event arrives once and in order. Senders retry, so make the handling safe to repeat.
- Doing slow work before replying. Acknowledge the message quickly and do the heavy work afterwards, or the sender may treat the delivery as failed.
- Leaving the test address in place. Many tools use one URL for testing and another for the live workflow.
Questions people ask
What is the difference between a webhook and an API?
With an API, your software sends a request when it wants something. With a webhook, the other service sends a request to you when an event happens. Many integrations use both.
Are webhooks secure?
They can be. Use HTTPS, verify the signature the sender includes, and keep the signing secret private. A webhook URL on its own is not a secret.
What happens if my endpoint is down?
Most senders retry for a period and then give up. Stripe, for example, says it retries live deliveries for up to three days. Check the sender's documentation and its delivery log.
Sources
Stripe's documentation says to verify each event's signature, return a 2xx response quickly, guard against duplicate events and not rely on events arriving in order. It retries live deliveries for up to three days.
Stripe Docs: Receive Stripe events in your webhook endpoint read 13 October 2026
n8n registers a test webhook URL while you build and a separate production URL once the workflow is published.
Every link was opened on 13 October 2026. Products and policies change, so check the source before you rely on a figure.