One mode has been missing all along

Lay the triggers from the earlier parts side by side and something stands out.

• Manual Trigger (Part 7) — the workflow only moves when you press the button.
• Schedule Trigger — the time comes and the workflow moves by itself.
• Gmail / Slack / Sheets Trigger (Part 8) — the SaaS side has a new event, and n8n polls for it on a timer to bring it back.
• The HTTP Request node (Part 9) — n8n goes out and calls someone else's API.

What they share is that n8n is always the one making the move. One mode is missing: an outside system wants to wake your workflow up. That is exactly what the Webhook node does.

flowchart LR
  subgraph IN["This part: something outside makes the move"]
    direction LR
    D["A form, a LINE message,
a door sensor, a git push,
a payment"] --> E["Webhook node,
one URL, always answering"]
    E --> F["The rest of your workflow"]
  end
  subgraph OUT["Parts 7 to 9: n8n makes the move"]
    direction LR
    A["A clock, or you
pressing the button"] --> B["Your n8n workflow"]
    B --> C["Somebody else's API,
called by HTTP Request"]
  end

Webhooks come up in far more situations than you would expect:

Put simply: if the other system has a “webhook” or “callback URL” field you can fill in, it can call into n8n. When you add a Webhook node to a workflow, n8n hands you a URL that looks like this:

Anyone who calls that URL — a person, a server, LINE, Home Assistant, a curl command — triggers your workflow. Everything that comes in becomes the $json of the first item, so the nodes after it can pull values out with an ordinary expression such as {{ $json.name }}. Three places hold the incoming pieces, and knowing which is which saves you the most common mapping mistake:

In other words, the Webhook node turns your workflow into a simple HTTP API. Any service that knows the URL can trigger it. That is also why Zapier and Make each ship a webhooks trigger of their own — it is the bridge every automation platform shares.

Two URLs, and the one that quietly stops listening

Open the Webhook node's settings panel and you see two URLs. This is the first real trap, and it catches almost everybody once.

Three differences between them are small on the screen and large in practice:

• The paths differ. The Test URL is usually /webhook-test/xxx and the Production URL is /webhook/xxx. Look carefully at which one you are copying out of the node panel.
• The Test URL takes one event and then closes itself. That suits tweaking fields and reading the shape of the incoming data, one call at a time.
• The Production URL does not show up as a live preview on the canvas. To see the runs that really happened, open the Executions tab.

stateDiagram-v2
  direction LR
  [*] --> Saved
  Saved --> Listening: press Listen for test event
  Listening --> Saved: one event arrives, or nothing arrives for about two minutes
  Saved --> Active: Save, then switch Active on
  Active --> Saved: switch Active off
  note right of Listening
    The Test URL answers here, and nowhere else
  end note
  note right of Active
    The Production URL answers for as long as this lasts
  end note

Note the honest wrinkle in that table. The documentation says the listen session has no timeout; what people actually see is that it stops after roughly two minutes when nothing arrives. Both statements are in the source material and they do not agree, so do not build anything around the exact number — if the node has gone quiet, press the button again and move on.

Catch a form submission and put it in a Google Sheet

The most classic starter example, and the most immediately useful: expose one URL, let a web form POST what the user typed, and have n8n write it into Google Sheets automatically. Once this works you can wire it straight to the contact form on your own site or landing page. The whole thing is two nodes: an outside POST hits the Webhook node, and the data flows on to the next node to do the work.

1. Step 1

   Create a workflow and make Webhook the first node

   Top right, + Add workflow, and you land on an empty canvas. Click the + in the middle, search the nodes panel for Webhook — it sits under the Triggers category — and add it.

2. Step 2

   Set the HTTP Method and the Path

   With the Webhook node open, set HTTP Method to POST, because a form sending data in uses POST by default. Then give Path any memorable English name — form-contact, say. It is appended to the end of the URL. As soon as that is set, the bottom of the node panel shows both URLs:

   Test URL: https://n8n.woowtech.io/webhook-test/form-contact

   Production URL: https://n8n.woowtech.io/webhook/form-contact
3. Step 3

   Press Listen for test event and call it once with curl

   Press Listen for test event at the top right of the node. It goes into waiting mode — it ends by itself after the first event, and in practice it also stops after about two minutes if nothing arrives. Open a terminal and send fake data to the Test URL:

   curl -X POST https://n8n.woowtech.io/webhook-test/form-contact \
-H "Content-Type: application/json" \
-d '{"name":"Wang Xiaoming","email":"[email protected]","message":"I would like a quote"}'

   Back on the canvas, the Webhook node turns green and the output panel on the right shows the JSON you just sent. The moment you can see the data arrive, this step is finished.

4. Step 4

   Wire up a Google Sheets node set to Append Row

   Add a Google Sheets node after the Webhook node and set Operation to Append Row in Sheet. Pick your credential, creating one the first time round — Part 10 covers that. Choose a spreadsheet and a sheet that already has the columns name, email, message and received_at.

5. Step 5

   Map the fields, in Expression mode

   Switch every field in the Columns block to Expression mode and map them like this:

   name → {{ $json.body.name }}

   email → {{ $json.body.email }}

   message → {{ $json.body.message }}

   received_at → {{ $now.toISO() }}

   The body in the middle of each one is the part people forget. The Webhook node does not flatten the request for you — it keeps the body under $json.body, the query string under $json.query, and the headers under $json.headers. Writing {{ $json.name }} here would quietly give you nothing.

6. Step 6

   Execute step, and check the Sheet really has a new row

   Press Execute step on the Google Sheets node. It sends the item the Webhook node just received. Open Google Sheets and look for a row with that data in it. If it is there, the whole chain is connected.

7. Step 7

   Save, then switch Active on

   Press Save at the top right, then flip the Active toggle at the top right to on. This step is the one people skip, and skipping it is why the Production URL answers 404.

8. Step 8

   Verify by calling the Production URL once

   Back in the terminal, call the Production URL this time — the same command with /webhook-test/ replaced by /webhook/:

   curl -X POST https://n8n.woowtech.io/webhook/form-contact \
-H "Content-Type: application/json" \
-d '{"name":"Li Xiaohua","email":"[email protected]","message":"Live submission"}'

   Another row appears in the Sheet. That URL is now ready to hand to an outside frontend engineer or a customer. For the history of what has come in, open the Executions tab in the sidebar.

The two dropdowns that decide almost everything

Once the URL exists, two settings do most of the work: which HTTP method the node answers on, and what n8n sends back to whoever called. Get either wrong and the symptoms look nothing like the cause.

HTTP Method: which one to use when

The HTTP Method dropdown offers GET, POST, PUT, PATCH, DELETE and HEAD. In practice you use the first two often; the rest come up when you are building a REST-style API for somebody else.

Respond: what n8n sends back, and who waits

The Respond option decides what HTTP response n8n returns when an outside call comes in. This matters more than it looks. Services like LINE, Slack and Stripe read what you return to judge whether the webhook succeeded. Answer wrong and they may retry, which gives you duplicate runs, or disable your webhook outright.

sequenceDiagram
  participant S as The calling service
  participant W as Webhook node
  participant N as The nodes after it
  participant R as Respond to Webhook
  Note over S,R: Respond set to Immediately
  S->>W: POST, their timer starts
  W-->>S: 200 OK, empty body, at once
  W->>N: the rest runs in the background
  Note over S,R: Respond set to When Last Node Finishes
  S->>W: POST, timer still running
  W->>N: every node runs, caller waits
  N-->>S: the last node's output is the reply
  Note over S,R: Respond set to Using Respond to Webhook Node
  S->>W: POST
  W->>R: the run reaches the node you chose
  R-->>S: your status code, headers, body
  R->>N: anything wired after it runs on

The Respond to Webhook node is the key to that third mode. Put it after whichever node you want to answer from — it does not have to be the last one — and you get three settings:

The services that will call you, and how to keep everyone else out

Almost every modern SaaS has a webhook feature. When they have an event to tell you about, they POST to a URL you name. Put your Webhook node's Production URL in that field and the two are wired together. These are the ones you meet most often.

Once the URL is out there, anyone can call it

That is not a figure of speech. Somebody malicious can stuff junk into your Sheet, fire an expensive AI Agent over and over, or send spam LINE messages on your account. There are several ways to protect it, from the simplest to the most advanced.

A customer messages on LINE, and an AI Agent answers

This is where the whole series comes together in one build: Webhook to receive, AI Agent (Part 16) to think, HTTP Request (Part 9) to answer, an expression to grab the payload, and Credentials to hold the token. Every piece was learned in its own part; here they are simply joined into one line.

flowchart TD
  U["A customer types a message
in the LINE chat"] --> L["The LINE platform POSTs
to your Webhook URL"]
  L --> W["Webhook node
POST, path line-bot,
Respond set to Immediately"]
  W -.->|"200 back within 3 seconds"| L
  W --> A["AI Agent
with a Chat Model attached"]
  A --> H["HTTP Request
POST to the LINE Reply API"]
  H --> B["The reply appears
in the customer's chat"]

1. Step 1

   Create a Messaging API channel in the LINE Developers Console

   Go to developers.line.biz and sign in, create a Provider, then add a Messaging API channel. Fill in the basics and submit.

2. Step 2

   Get the Channel Secret and the Access Token

   Once the channel exists, go to the Basic settings tab and copy down the Channel Secret. At the bottom of the Messaging API tab, press Issue under Channel Access Token to generate one, and copy that too. Both of these go into n8n Credentials in a moment — not into a node parameter, and not into a note you paste into a group chat.

3. Step 3

   New n8n workflow, with a Webhook node on POST

   Create a new workflow and add a Webhook node: Method = POST, Path = line-bot, Respond = Immediately, because LINE wants a 200 within 3 seconds. Copy the Production URL for later — you cannot use it yet, since the workflow is not Active. For now press Listen for test event and build against the Test URL.

4. Step 4

   On the LINE side, paste the n8n URL into Webhook URL

   Back in the LINE Console on the Messaging API tab → Webhook settings → paste the n8n Test URL → turn on Use webhook. Press Verify and it should say Success, because LINE really does call it once.

5. Step 5

   Add the bot as a friend and send it a message

   Scan the QR code shown in the LINE Console with your phone to add the Official Account as a friend, and send it a “hello”. Back on the n8n canvas, the Webhook node turns green and the output shows LINE's payload. Find the path to the message text. It is usually one of these:

   {{ $json.body.events[0].message.text }}

   {{ $json.body.events[0].replyToken }}

   {{ $json.body.events[0].source.userId }}

   The first is the text the user typed, the second is the token you reply with, and the third is the user's ID.

6. Step 6

   Add an AI Agent node to produce the reply

   Add an AI Agent node. Use an expression in its Text field to bring in the user's message: {{ $json.body.events[0].message.text }}. Attach a Chat Model — OpenAI GPT-4o mini, or another. Add Memory if you want it to remember the conversation.

7. Step 7

   Add an HTTP Request node to call the LINE Reply API

   Add an HTTP Request node: Method = POST, URL = https://api.line.me/v2/bot/message/reply, Authentication set to Header Auth, carrying Authorization: Bearer <your-channel-access-token>. The body is JSON, with three values in it:

   Field	Value	Where it comes from
   replyToken	"{{ $('Webhook').item.json.body.events[0].replyToken }}"	$('Webhook') reaches back past the AI Agent node to the Webhook node's own item
   messages[0].type	"text"	A fixed value — this reply is a plain text message
   messages[0].text	"{{ $json.output }}"	$json.output is the reply the AI Agent node has just produced

   In the JSON itself, messages is an array holding one object, so those last two rows sit together inside a single { "type": ..., "text": ... } entry.

8. Step 8

   Save, switch Active on, then move LINE to the Production URL

   Save, then switch Active on. Back in the LINE Console, change the Webhook URL from the Test URL to the Production URL — the one ending /webhook/line-bot. Send another message from your phone, and the answer comes back in a second.

Read the status code first, then work backward

Almost every webhook fault announces itself in what the caller gets back. Start there and you can usually name the cause before you open a single node.

flowchart TD
  A["An outside call is not
reaching your workflow"] --> B{"What does the
caller get back?"}
  B -->|"nothing, on test"| B1["Listen mode is off.
Press it again"]
  B -->|"404"| C{"Is it Active?"}
  C -->|"no"| C1["Save, then
Active on"]
  C -->|"yes"| C2["Check the Path.
Case sensitive"]
  B -->|"405"| D["Methods differ.
Match both sides"]
  B -->|"401"| E["Auth header wrong.
Test it with curl"]
  B -->|"200, empty"| F["No Content-Type.
Ask for JSON"]

Each box names the cause and the first move. The table below is the long version of the same five answers: what to compare on the node, what to ask the caller to send, and the limits that start to bite once the traffic is real.

What you can actually build now

That is the whole guide. From Part 1, what n8n is, to this one, the series took you from “I have heard of Zapier” to “I can wire up a LINE bot myself and give a workflow a brain that thinks.” Concretely, here is what you can do:

The rest is doing it. The honest advice to finish on: find one thing your company has done over and over in the past three months — tidying a report by hand every morning, sending the same reminder email every week, replying to every LINE customer with the same canned message — and open a workflow that kills it off. The moment your first workflow goes live, you tend to realize it really did not need a person at all. And then you will not be able to stop.

And when you get stuck along the way:

• You forgot how to configure a node — go back to the part that covers it; the guide's contents list them all.
• A node has a red border and will not run — open its error message first, then the error-handling material in Part 12.
• You cannot find a setting — check the settings reference in the full guide rather than clicking through the panel at random.
• You want to go deeper on self-hosting — the guide's architecture appendix covers how it works underneath.
• Nobody has written about your exact problem — ask the official n8n community at community.n8n.io. Plenty of people are walking the same road.

May your workflows all run smoothly, may they go live without incident, and may the automation land well enough that somebody notices.

Where to go from here