How to Use Webhooks in n8n (Step-by-Step)
This page may contain affiliate links. If you buy through them we may earn a commission at no extra cost to you.
Direct answer: a webhook in n8n is a Webhook node that gives your workflow a unique URL; any external service that sends an HTTP request to that URL triggers the workflow, with the request's body, headers, and query parameters available as the node's output. Add the node, choose GET or POST depending on what's calling it, and you have a working test URL in under a minute. The parts that trip people up are the test-vs-production URL split, remembering to respond to the caller, and, for self-hosted instances, the HTTPS requirement, all covered below.
Step 1: Add a Webhook node and understand its two URLs
Start a new workflow and add a Webhook node as the trigger. n8n immediately shows two URLs: a test URL that only receives requests while you have the workflow open in the editor with "Listen for test event" active, and a production URL that works once the workflow is saved and the workflow's Active toggle is switched on. Build and debug against the test URL first; switching to production too early just means you're debugging a workflow that silently isn't listening, since the production path requires that explicit activation step.
Step 2: Choose the HTTP method and path
Set the method to match what's calling it. GET works for simple pings or services that just hit a URL with query parameters. Most real integrations, form builders, payment processors, chat platforms, send POST with a JSON body, and n8n parses that body automatically into $json.body on the node's output, no manual parsing needed. You can also customize the path segment of the URL (the part after /webhook/) to something readable, which matters once you have more than one or two webhooks running and need to tell them apart in logs.
Step 3: Send a test request and inspect the payload
With "Listen for test event" active, send a request to the test URL, from a browser for a quick GET check, or from a tool like Postman or curl for a POST with a body. n8n captures the first request and populates the node's output pane with the full payload: headers, query parameters, and body. This is the step to actually look at closely before building downstream logic; a form tool or third-party service often sends fields nested deeper than you'd expect, and guessing the shape instead of inspecting a real payload is the most common source of a workflow that builds cleanly and then fails on the first real request.
Step 4: Respond to the caller
Every webhook call expects a response, and n8n won't send one automatically unless you tell it to. The Webhook node's own settings include a Respond option: "Immediately" (acknowledges the request right away, before the rest of the workflow runs) or "When Last Node Finishes" (waits for the workflow to complete, then responds). For more control over exactly what gets sent back, status code, custom JSON body, add a Respond to Webhook node at the point in your workflow where you want the reply to go out. Skipping this entirely is fine for a webhook that's purely internal plumbing, but any service expecting a meaningful response (confirming an order, returning a calculated value) needs one of these configured, or the caller sees a timeout regardless of whether your workflow actually succeeded.
Step 5: Secure the endpoint before it does anything real
A webhook URL isn't a secret once it's been shared or logged anywhere, request logs, a browser history, a copied Slack message. For anything beyond a low-stakes internal trigger, turn on the Webhook node's built-in header authentication, which checks an incoming request for a shared secret you define, and reject anything that doesn't match. Services that sign their payloads cryptographically, Stripe and GitHub both do this, let you go a step further: validate the signature in a Code node before the workflow proceeds, which also protects against a replayed or tampered payload, not just an unauthorized caller.
Step 6: Handle the self-hosted HTTPS requirement
If you're running n8n on your own server rather than n8n Cloud, the production webhook URL has to be reachable over HTTPS with a valid TLS certificate for most external services to deliver to it at all; several platforms (Telegram and WhatsApp's APIs among them) refuse to call an endpoint that isn't. Our guide to self-hosting n8n covers the reverse-proxy and certificate setup this requires; n8n Cloud users get this for free and can skip straight to building the workflow.
Where webhooks fit into a bigger workflow
A webhook is a trigger, not the whole automation, and it's the backbone of most of the channel-specific guides on this site. Our guide to building a Telegram bot with n8n uses a dedicated Telegram Trigger that's really a packaged webhook under the hood, and our guide to automating WhatsApp with AI relies on the same request-response pattern described here against Meta's Cloud API. If you're building a workflow that reacts to a form submission to kick off something like automated lead follow-up, a plain Webhook node connected to your form tool is usually the simplest trigger available, often simpler than whatever native integration the form tool offers.
Common pitfalls
The most common failure is testing against the test URL and then handing the production URL to an external service without ever activating the workflow; n8n's production webhook stays silent until Active is switched on, with no error shown anywhere obvious. The second is forgetting the response step, a workflow that runs perfectly but never calls Respond to Webhook leaves every caller waiting on a timeout. Third, for anything parsing a POST body, double-check the content type the sender actually uses; a sender posting form-encoded data instead of JSON lands in a different field than $json.body, and assuming the JSON shape without checking produces a workflow that looks broken when the trigger is actually working fine.
Webhook vs. the alternative trigger types
| Webhook node | Polling trigger (e.g. schedule + API check) | Native app trigger (e.g. Gmail, Airtable) | |
|---|---|---|---|
| Latency | Near-instant | Delay equal to your polling interval | Usually near-instant, vendor-dependent |
| Setup effort | Low, plus securing the endpoint | Low, but costs API calls on every poll | Lowest, if the app has a native n8n node |
| Works with | Any service that can send an HTTP request | Any service with a readable API, no push support needed | Only apps n8n has a dedicated trigger for |
| Best for | Real-time events from a service that supports webhooks | Services with no webhook support | Common SaaS tools n8n already integrates |
A webhook also makes a convenient entry point for feeding freshly collected data into the rest of a workflow; if you're pulling that data in by scraping a website with n8n rather than waiting on an inbound call, the trigger logic differs but the response and security steps covered here still apply once the data lands.
For the protocol-level reference behind all of this, n8n's own documentation covers additional Webhook node options, like binary data handling and multiple HTTP methods on one node, that go beyond what a single getting-started guide needs to cover. Get the test-to-production handoff and the response step right first; those two account for most of the "it worked in testing but not in production" reports we've seen, far more than anything exotic in the payload itself.
Frequently asked questions
What's the difference between the test and production webhook URLs?
The test URL only receives calls while you have the workflow open in the editor with 'Listen for test event' active; it's for building and debugging. The production URL works once the workflow is saved and toggled Active, independent of whether the editor is open, and it's the one you give to any real external service.
Why isn't my webhook receiving any data?
The two most common causes are an inactive workflow (n8n only listens on the production URL once Active is toggled on) and, for self-hosted instances, a webhook URL that isn't reachable over HTTPS with a valid certificate. A third, less common cause is calling the test URL from a service you expect to run continuously; test URLs stop listening once you close the editor or send a real event.
How do I send data back to whatever called the webhook?
Add a Respond to Webhook node at the point in your workflow where you want to reply, or set the Webhook node's own Respond option to 'Immediately' or 'When Last Node Finishes' if you don't need to control the exact response payload. Without one of these, the caller gets a timeout even if the rest of your workflow completed successfully.
Can I secure a webhook so random requests can't trigger it?
Yes. The Webhook node supports header-based authentication (checking for a shared secret in a request header) directly in its settings, and for services that sign their payloads, like Stripe or GitHub, you can validate that signature in a Function or Code node before letting the workflow proceed. Treat the raw URL as discoverable, not as your only line of defense.