The Webhook Node
Gives your workflow its own URL — the most common way an automation actually gets started.
What it actually does
Most nodes in n8n do something once a workflow is already running. The Webhook node is different — it’s usually what starts the workflow in the first place. When you add one, n8n generates a unique URL. Any external service that can send an HTTP request to that URL — a form submission, another app’s “when X happens” notification, a script you write yourself — can trigger your workflow the moment something happens, in real time.
This is the difference between automation that reacts instantly and automation that only checks in periodically. A Schedule Trigger might check for new orders every five minutes; a Webhook fires the instant an order actually comes in, because the order system pushes the data to n8n directly rather than n8n having to go looking for it.
Every Webhook node has two URLs: a Test URL (only listens while you’re actively building and testing in the editor) and a Production URL (works continuously once the workflow is activated). Mixing these up — testing against the Test URL, then wondering why the live integration isn’t firing — is extremely common early on.
A worked example
A contact form on a website submits to n8n’s Webhook URL instead of emailing you directly. The Webhook node receives the submitted fields (name, email, message) as JSON, which then flows into an Edit Fields node to tidy them up, and finally into a Gmail node that sends you a formatted notification — all within a second or two of the visitor hitting “Submit.”
Another common pattern: a third-party app (Stripe, Typeform, a CRM) has its own “webhook” setting somewhere in its integrations page. You paste n8n’s Production URL in there, and from that point on, that app pushes data to your workflow automatically every time the relevant event happens — no polling, no delay.
The mistake almost everyone makes first
Forgetting that the workflow needs to be Activated (the toggle in the top-right of the n8n editor) for the Production URL to actually work. It’s easy to build and test a webhook workflow successfully using the Test URL, then wire it up in an external app using the Production URL — and have nothing happen, because the workflow was only ever tested, never switched on. If a webhook seems to be receiving nothing, activation status is the first thing worth checking, before assuming the URL or the sending app is misconfigured.
Related nodes
HTTP Request — the reverse direction, calling out instead of receiving in · Edit Fields — tidy up incoming webhook data before using it