n8n Webhook 教學：從表單進線到 API 串接的完整實戰

n8n Webhook 教學，從表單進線、付款通知到內部 API，教你設定 Test URL、Production URL、回應、驗證與除錯。

發佈於： 2026-06-23 | 更新於： 2026-06-24

入門 n8n n8n Webhook Webhook 教學

內容查核： 2026-06-23 來源查核： 2026-06-23

你會查 n8n Webhook，通常不是因為想研究 HTTP 名詞，而是手上已經有一個流程卡住了：

官網表單送出後，只寄 Email 太慢，你想把名單直接丟進 CRM、Slack 或 Google Sheets。
金流付款成功後，想自動開通帳號、寄通知、更新訂單狀態。
自家系統有新訂單、新客服單、新會員註冊，但 n8n 沒有現成 trigger。
你把 Test URL 貼到外部服務，測試時有反應，上線後卻收不到資料。
外部系統一直 timeout，不知道 n8n 到底該立刻回應，還是等整條 workflow 跑完再回。

Webhook 的作用很簡單：給外部系統一個網址，當事件發生時，把資料送進 n8n，讓 workflow 開始跑。但真正難的不是新增 Webhook 節點，而是搞清楚測試 URL、正式 URL、資料格式、回應方式、驗證和除錯。

這篇會用「表單進線」當主案例，帶你從 Test URL 收第一筆資料，到 Production URL 上線，再補上安全檢查。看完後，你應該能回答三個問題：外部系統要打哪個 URL、n8n 收到後要怎麼回應、出錯時要去哪裡查。

如果你還不熟 n8n 節點，可以先看 n8n 節點大全；如果你想看完整場景，回到 n8n 教學 hub。

先判斷你的 Webhook 屬於哪種需求

需求	典型場景	設計重點
只要接收資料	表單、問卷、活動報名	`POST` 收 payload，整理欄位，寫入資料表或通知
需要立刻回應	前端表單、內部 API endpoint	用 `Respond to Webhook` 控制回應內容與狀態碼
第三方事件通知	付款成功、GitHub issue、CRM event	驗證來源，保存 event_id，避免重複處理
內部系統同步	新訂單、新會員、新客服單	設定 timeout、錯誤回應、重試策略與 log
對外提供簡單 API	查詢狀態、觸發任務、產生草稿	不要把慢任務放在同步回應裡，必要時改成 async

Webhook 在 n8n 裡扮演什麼角色？

Webhook 是 trigger node。也就是說，它通常放在 workflow 第一格，負責等待外部請求。當外部服務呼叫這個網址，n8n 就會接收資料，並把資料交給下一個節點。

你可以把它想成一個接待櫃台：

外部事件	Webhook 收到什麼	後面可以做什麼
表單送出	姓名、Email、訊息、來源頁	分級、寫 CRM、通知業務
付款成功	訂單 ID、金額、付款狀態	開通帳號、寄信、更新資料庫
GitHub issue	標題、內容、作者、repo	AI 分類、補 label、通知 Slack
內部系統事件	customer_id、event_id、payload	查資料、同步、回寫結果

Test URL 和 Production URL 差在哪？

n8n Webhook 會提供兩種網址：Test URL 和 Production URL。

URL	用途	注意事項
Test URL	開發、測試、看資料格式	要按 `Listen for test event` 或執行 workflow，資料才會顯示在畫面上
Production URL	正式外部系統呼叫	workflow publish / active 後使用，資料要到 executions 裡查看

新手最常犯的錯，是把 Test URL 貼到正式系統。測試時可以，但正式串接要換成 Production URL，否則你會遇到「測試時有反應，上線後沒反應」或「workflow 沒開就收不到」這類問題。

不想上線出包，照這個順序做

很多 webhook 問題不是 n8n 壞掉，而是測試順序錯了。建議你照下面順序跑一次：

步驟	要確認什麼	常見錯誤
1. 先用 Test URL 收一筆資料	n8n 畫面看得到 payload	外部服務送的是 form-data，但你以為是 JSON
2. 整理欄位	後續節點只吃固定欄位名稱	同一欄位有時叫 `email`，有時叫 `mail`
3. 決定回應方式	外部系統要不要等結果	workflow 跑太久，外部服務 timeout
4. 換成 Production URL	workflow active 後才貼到正式系統	把 `webhook-test` 留在正式設定
5. 加驗證與去重	確認來源可信、事件不重複執行	同一筆付款通知觸發兩次，重複寄信或開通
6. 看 executions	正式資料不會跳在測試畫面	以為沒收到，其實在 executions 裡

如果你只是做內部 demo，可以先跑到第 3 步。但只要 webhook 會接客戶資料、付款、CRM 或正式訂單，就不要跳過第 5 步。

第一個 Webhook workflow：表單進線

先做一條最小流程：

新增 Webhook 節點。
HTTP Method 選 POST。
Path 設成 lead-intake。
按 Listen for test event。
用表單、Postman、curl 或瀏覽器工具送一筆測試資料。
後面接 Edit Fields (Set)，整理 name、email、message。
接 Slack、Send Email 或 Google Sheets。

測試用 JSON 可以長這樣：

{
  "name": "Mason Chen",
  "email": "[email protected]",
  "message": "想了解 n8n 自動化導入報價",
  "source": "website_contact_form"
}

用 curl 測試時，大概是這種形狀：

curl -X POST "https://your-n8n-domain/webhook-test/lead-intake" \
  -H "Content-Type: application/json" \
  -d '{"name":"Mason Chen","email":"[email protected]","message":"想了解 n8n 自動化導入報價"}'

測試通過後，再把 URL 換成 Production URL，並啟用 workflow。

HTTP Method 怎麼選？

Webhook 節點支援常見 HTTP method。你不用全背，只要先記下面幾種。

Method	適合用途
`GET`	查詢、簡單測試、外部服務只能用 GET 時
`POST`	最常用；送表單、事件、JSON payload
`PUT` / `PATCH`	表示更新資料，常見於內部 API 設計
`DELETE`	表示刪除事件或撤銷事件，正式使用要很小心

如果你是接表單、付款、CRM 或 GitHub，大多數情況會用 POST。

Webhook 回應要怎麼設計？

外部系統呼叫 webhook 後，通常會期待 n8n 回一個 HTTP response。n8n 常見三種做法：

回應方式	適合場景
Immediately	外部系統只需要知道 workflow 已啟動
When Last Node Finishes	外部系統需要最後一個節點的結果
Respond to Webhook	你要精準控制 response body、status code、headers

如果你只是收表單，Immediately 通常夠用。如果你把 n8n 當成一個小 API，例如「查訂單狀態後回傳 JSON」，就應該用 Respond to Webhook，比較可控。

回傳格式可以像這樣：

{
  "ok": true,
  "ticket_id": "T-1001",
  "next_action": "sales_follow_up"
}

重要提醒：如果 workflow 要跑很久，不要讓外部系統一直等。可以先立即回應 accepted，再用 Slack、Email 或另一個 API callback 通知結果。

Webhook 安全：正式上線前一定要做

Webhook 是入口，入口就有風險。正式使用時至少檢查下面幾項。

檢查項	為什麼重要	做法
Authentication	避免任何人都能打你的 URL	使用 Basic auth、Header auth 或 JWT auth
IP whitelist	只允許特定來源呼叫	若對方 IP 固定，可開 IP whitelist
Secret header	驗證來源是否可信	要求 `X-Webhook-Secret` 或簽章
CORS	前端直接呼叫時才需要開	不要無腦允許所有 origin
Payload size	避免大檔案或異常 payload	先限制表單和檔案大小；自架可調整 payload 上限
Idempotency	避免同一事件重送造成重複寫入	用 event_id、order_id、email 做唯一鍵
Logging	出事要能查	保留 execution log 與外部 request id

n8n 官方文件也提醒 Webhook 可設定 authentication、IP whitelist、raw body、CORS、response header 等選項；自架環境還要注意 payload size 與反向代理設定。

常見實戰場景

場景一：官網表單進線

流程：

Webhook 接表單資料。
Edit Fields (Set) 統一欄位。
If 判斷是否包含「報價」、「合作」、「預算」。
高意圖送 CRM，低意圖進 Google Sheets。
Slack 通知負責人。

這是最適合新手的場景，因為資料簡單、商業價值清楚、出錯也容易修正。

場景二：付款成功後通知

流程：

金流系統呼叫 Webhook。
用 HTTP Request 查訂單細節。
If 確認付款狀態是 paid。
更新資料庫或 CRM。
寄出開通信或通知內部團隊。

這種流程一定要做 idempotency，因為付款 webhook 很常有重送機制。同一個 payment_id 不應該開通兩次。

場景三：n8n 當內部 API endpoint

流程：

內部系統呼叫 Webhook，帶 customer_id。
n8n 用 HTTP Request 或資料庫節點查資料。
整理結果。
Respond to Webhook 回傳固定 JSON。

這種做法適合快速 prototyping，但正式系統要注意權限、延遲、錯誤碼和監控。

常見問題

Webhook Test URL 可以正式使用嗎？

不建議。Test URL 是給開發測試用；正式串接應該使用 Production URL，並確保 workflow 已 publish 或 active。

Webhook 收不到資料怎麼查？

先確認 URL 是 test 還是 production、workflow 是否正在 listen 或已啟用、method 是否一致、外部服務有沒有送到正確 path、authentication 是否通過。

外部系統一直 timeout 怎麼辦？

不要讓 webhook 等完整長流程。先立即回應 accepted，再把耗時任務放後面跑，或用 callback / Email / Slack 通知結果。

Webhook URL 被別人知道會怎樣？

如果沒有驗證，別人可能亂打你的流程。所以正式使用時要加 authentication、secret header、IP whitelist 或其他驗證設計。

下一步

如果你要把 webhook 收到的資料交給 AI 判斷，可以接著看 n8n AI Agent 教學：Tools、Memory、Human Review 實戰。如果你只是想先把所有常用節點搞懂，回到 n8n 節點大全。

參考資料

№ · further reading