Core Concepts 6 min read Updated Sep 10, 2026

Webhooks, Explained

Every trigger you've used so far either waits for you to click a button or checks on a schedule. A webhook flips that: instead of n8n asking "did anything happen yet?", the other system tells n8n the instant something happens. It's the difference between checking your mailbox every hour and having mail dropped directly on your desk.

How a webhook works, mechanically

Add a Webhook trigger node to a workflow, and n8n generates a unique URL for it - something like https://your-instance.app/webhook/abc123. Give that URL to whatever system needs to notify you: a form tool, a payment processor, a custom app, even another n8n workflow. When that system sends an HTTP request to the URL, n8n receives it, and the workflow runs with that request's data as the first item.

Version note: the webhook URL path format changed in recent n8n versions - if you're copying a URL from an older tutorial or an existing workflow, double-check it matches what your current instance actually generates rather than assuming the format.

Test URL vs Production URL

Every Webhook node actually has two URLs. The Test URL only works while you have the workflow open and are actively listening for a test call - perfect for building and debugging. The Production URL only works once the workflow is saved and toggled Active, and it's the one you hand to a real external system. Mixing these up - testing against a URL that only works while editing, or wondering why nothing fires when the workflow is still inactive - is the single most common webhook mistake.

Responding to the caller

By default, a webhook immediately returns a generic "workflow started" response the instant it receives the request, before the rest of the workflow even finishes running. If the calling system expects a real response - a confirmation, a computed value, a redirect - add a Respond to Webhook node at the point in the workflow where you're ready to answer, and set the Webhook node's response mode to "When Last Node Finishes" or "Using Respond to Webhook Node" depending on your version.

Securing a webhook

A webhook URL is effectively public unless you protect it - anyone with the URL can trigger the workflow. For anything beyond casual testing, add authentication: n8n's Webhook node supports header-based auth (checking for a secret token in an incoming header) and basic auth out of the box. For webhooks from major platforms (Stripe, GitHub, etc.), also verify the request's signature against a shared secret rather than trusting the payload blindly.

When to use a webhook vs. an app trigger

If the app you're connecting to has a native n8n trigger node (Airtable, Google Sheets, Typeform, etc.), use that first - it's built and maintained for you. Reach for a raw Webhook node when the source system isn't natively supported, when you're building your own internal tool that needs to call into n8n, or when you need lower latency than an app's built-in trigger polling interval provides.

Next up: what happens when a node in a webhook-triggered (or any) workflow fails - error handling and retries.
Share this guide

Was this guide helpful?

Thanks for the feedback!

Want more hands-on AI builds like this?

APA Mastery runs live, practical sessions on working with modern AI tools - not just theory.

See What's On →
← PreviousCredentials & Connecting Apps