Most automation tools rely on polling — they check an external service every few minutes to see whether anything has changed. It works, but it is slow, wasteful, and often introduces unnecessary delays. Webhooks take the opposite approach. Instead of your automation tool asking “has anything happened?”, the external service calls your automation the moment something does. In n8n, the Webhook node is the mechanism that makes this possible: it listens at a unique URL and fires your workflow the instant it receives an incoming HTTP request. Whether you are processing contact form submissions, reacting to Stripe payments, or responding to a GitHub push, webhooks are the fastest and most reliable way to connect external systems to your n8n workflows.
How the n8n Webhook Node Works
When you add a Webhook node to a workflow, n8n assigns it a unique URL. Any application that can send an HTTP request — which is virtually all of them — can trigger your workflow by calling that URL. The node receives the incoming request, extracts the payload (the body, headers, and query parameters), and passes that data downstream to the next node. From that point, your workflow can do anything: write to a database, send an email, post to Slack, or call another API.
n8n provides two URLs for every webhook: a test URL for use during development, and a production URL for use once the workflow is active. The test URL only listens when you are actively running a test inside n8n. The production URL listens continuously once the workflow has been activated. This distinction matters — during development you use the test URL so you can inspect the incoming payload in real time; in production you activate the workflow and switch to the production URL.
Setting Up Your First Webhook
- Add a Webhook Trigger node. Open a new workflow and select Webhook as the trigger node. n8n will generate your test and production URLs immediately.
- Copy the test URL. You will use this during development. The production URL — which follows the same path but uses your live domain — is what you configure in external services once the workflow is ready.
- Configure the HTTP method. For most use cases, POST is correct. GET webhooks are useful when an external service only supports GET requests and passes data as query parameters, but POST with a JSON body is far more common and flexible.
- Set the response mode. “Immediately” sends a 200 OK response as soon as the webhook is received, then continues processing in the background — ideal when the calling service does not need a response. “After last node” waits until the workflow finishes and returns the final output — required when you are building a synchronous integration where the calling app expects data back.
- Add authentication. Leave a webhook endpoint open and anyone who discovers the URL can trigger your workflow. Use Basic Auth or Header Auth to secure it. Header Auth is the more common approach: require a secret token in a custom header (for example,
X-Webhook-Secret) and validate it in your workflow logic.
Testing with curl
Before connecting a real application, verify that your webhook is receiving data correctly using curl. Click “Listen for Test Event” in n8n, then run the following in your terminal:
curl -X POST https://n8n.yourdomain.com/webhook/your-path
-H "Content-Type: application/json"
-d '{"name":"test","email":"test@example.com"}'n8n will display the received payload in the node output panel. You can now see the exact structure of the incoming data and reference it in subsequent nodes using expressions such as {{ $json.body.name }}. Once you are happy with the workflow, activate it and switch any external services to the production URL.
Three Practical Webhook Use Cases
1. Website Contact Form Submissions
Configure your contact form plugin or custom form to POST its data to the n8n webhook URL on submission. The Webhook node receives the name, email, and message fields, and your workflow can then send an internal notification, add the contact to your CRM, and reply to the user with an automated confirmation — all within seconds of them clicking Submit.
2. Stripe Payment Webhooks
Stripe is used widely by UK businesses for online payments, and its webhook system is one of the most mature in the industry. In your Stripe Dashboard, navigate to Developers → Webhooks and add your n8n production URL as an endpoint, selecting the payment_intent.succeeded or checkout.session.completed event. When a customer completes a payment, Stripe calls your webhook instantly. Your n8n workflow can then trigger a fulfilment process: send an order confirmation email, provision access to a digital product, update a spreadsheet, or create a record in your accounting software. Note that your webhook URL must be publicly accessible — it cannot be a localhost address. This is why running n8n on a VPS or behind a reverse proxy with a real domain is essential for production use.
3. GitHub Webhooks
In your GitHub repository settings, add your n8n webhook URL under Webhooks and select the “push” event. Each time code is pushed to the repository, GitHub sends a POST request containing the branch name, commit messages, and author details. Your n8n workflow can react by posting a Slack notification to your development channel, logging the push to a Google Sheet, or triggering a deployment pipeline.
Validating Webhook Signatures
Publicly accessible webhook endpoints are a potential target for spoofed requests. Stripe and GitHub both sign their webhook payloads with a secret, and you should always verify that signature before processing the request. In n8n, do this with a Code node placed immediately after the Webhook node.
For Stripe, the raw request body and the Stripe-Signature header are used to compute an HMAC-SHA256 signature using your webhook signing secret. Compare the computed signature to the one Stripe provides — if they do not match, halt the workflow. For GitHub, the process is identical using the X-Hub-Signature-256 header and your repository’s webhook secret. Rejecting unverified requests prevents bad actors from triggering your workflows with fabricated data.
Synchronous vs Asynchronous Handling
When a calling application expects an immediate response — for example, a chatbot integration or a payment provider expecting a specific reply — set the response mode to “After last node” and add a Respond to Webhook node at the end of your workflow to return the appropriate data. For background processing tasks such as fulfilment or notifications, use “Immediately” so the external service receives its 200 OK response without waiting for your workflow to complete. Mixing the two up is a common source of timeout errors.
Troubleshooting Tips
- Use webhook.site first. Before building your workflow, point the external service at webhook.site to inspect the exact payload it sends. This saves time spent debugging inside n8n before you even know what the data looks like.
- Check n8n execution logs. Every webhook trigger is recorded under Executions in the n8n sidebar. If a workflow fails silently, the execution log shows exactly which node errored and what data it received.
- Ensure your URL is publicly reachable. If the external service cannot reach your n8n instance, it will fail silently or return a connection error. Test reachability with curl from an external machine before assuming the problem lies in n8n itself.
- Do not confuse the test and production URLs. Configuring an external service with the test URL and then wondering why it stops working after you close the test panel is one of the most common beginner mistakes.
Related n8n Guides
- n8n — The Complete Self-Hosted Automation Guide
- What Is n8n? The Self-Hosted Automation Tool Explained
- How to Install n8n with Docker: Self-Hosted Setup Guide
- n8n vs Zapier vs Make: Which Automation Tool Should You Choose?
- How to Build Your First n8n Workflow: A Beginner’s Guide
