Webhook 串接萬物:讓任何服務都能觸發你的流程

上一課做完三個真實案例,你手上的流程有兩種啟動方式:排程(每天早上八點跑新聞摘要信)跟官方整合的觸發器(Gmail 收到信、表單有新回覆)。但你遲早會撞到這面牆:想串的服務不在 n8n 的節點清單裡——公司內部系統、某個冷門 SaaS、朋友寫的小工具、甚至你自己用 Vibe Coding 做的網站。難道每種服務都要等官方出整合?

不用。只要對方會發 HTTP 請求(幾乎所有網路服務都會),你就能用 webhook 接住它。這堂課學完,「n8n 有沒有支援某某服務」這個問題對你來說基本消失:有官方節點就用官方節點,沒有就丟一個 webhook 網址過去。這是從「會用自動化工具」升級成「什麼都能串」的分水嶺。

這堂學什麼

• webhook 是什麼:一個「門鈴」比喻講到你永遠不會忘,以及它為什麼比輪詢省錢又即時
• n8n Webhook 節點實戰:Test URL 和 Production URL 的差別(80% 的新手卡關都卡在這)
• Respond to Webhook:不只接收,還要回話——讓打進來的服務拿到你客製的回應
• 完整做一個 Telegram 記帳 bot:傳「午餐 120」,AI 解析後自動寫進 Google Sheets 並回覆確認
• 錯誤處理三道防線:節點重試、Error Workflow、出事直接通知你手機
• 安全:webhook URL 為什麼要當密碼保管,以及 Header Auth 怎麼設

觀念一:webhook 就是給你的流程裝門鈴

先講清楚沒有 webhook 的世界。假設你要「表單有新回覆就處理」,而這個表單服務沒有觸發節點,你只能用 Schedule 節點輪詢(polling):每 5 分鐘去問一次「有新資料嗎?」——就像你每 5 分鐘走去門口看一次有沒有包裹。

webhook 把方向反過來:你給對方一個網址(門鈴),有事他自己來按。事件發生的那一秒,對方主動對這個網址發一個 HTTP 請求,把資料一起送進來,你的流程當場啟動。兩個差別都是致命級的:

• 即時:輪詢最慢延遲一整個間隔;webhook 是秒級。做客服通知、訂單處理,這差距就是體驗的差距。
• 省錢:還記得第 1 課的計費模型嗎?n8n 按 execution 計費,每 5 分鐘輪詢一次,就算什麼事都沒發生,一個月也燒掉近 8,640 次 execution;webhook 一個月 100 筆事件就只算 100 次。在 Make 那邊差距更誇張,因為輪詢的每一步都吃 credit。免費版與 Starter 方案的額度,經不起輪詢這樣揮霍。

順帶一提,你其實早就用過 webhook 了:第 5 課的 Telegram 排程發文、以及等一下要用的 Telegram Trigger,底層全是 webhook——Telegram 收到訊息,就打 n8n 給它的網址。官方整合節點很多只是「幫你把門鈴裝好」的包裝而已。今天我們學的是自己裝門鈴,從此不依賴包裝。

觀念二:一次 webhook 呼叫的完整路徑

在 n8n 裡,webhook 相關的節點就兩個:Webhook(門鈴本體,收到請求就啟動流程)和 Respond to Webhook(把回應送回給呼叫方)。一次呼叫的路徑長這樣:

這張圖下半部是整堂課最重要的一個知識點:每個 Webhook 節點有兩條 URL。

• Test URL(路徑含 webhook-test):排練用。只有你在編輯器按下「Execute workflow」、節點進入等待狀態的那一小段時間有效,收到一次請求、在畫布上演完就熄火。拿來邊看真實資料長什麼樣、邊調流程。
• Production URL(路徑含 webhook):正式營業。workflow 右上角切成 Active 之後 24 小時待命。給外部服務填的永遠是這一條;而且它執行時畫布上不會動,紀錄要去左側的 Executions 頁看。

「測試時好好的,上線就沒反應」「明明打了怎麼畫布沒動」——這兩個經典災難,九成都是這兩條 URL 搞混造成的。常見坑第 1、2 條會給你完整的排查流程。

手把手實戰

實戰分兩段:先用 10 分鐘把 Webhook 節點的手感練起來,再做主菜——Telegram 記帳 bot。環境用第 3 課建好的 n8n(Cloud 或自架都可以,差異我會標出來)。

curl -X POST "https://你的n8n網址/webhook-test/你的路徑" \
  -H "Content-Type: application/json" \
  -d '{"name": "小明", "item": "咖啡", "amount": 65}'

{
  "status": "ok",
  "received_item": "{{ $json.body.item }}",
  "message": "已收到,流程處理完成"
}

/newbot
→ 它問 bot 顯示名稱:輸入 記帳小幫手
→ 它問 username:輸入一個以 bot 結尾的名字,例如 my_ledger_2026_bot
→ 它回你一串 API token,長得像 8123456789:AAHxK3...

你是記帳解析器。使用者會傳一句隨意的記帳訊息,請解析成 JSON,只輸出 JSON,不要任何其他文字、不要 markdown 程式碼框。

格式:
{"item": "品項", "amount": 金額數字, "category": "分類"}

分類只能從這裡選:飲食、交通、購物、娛樂、居家、其他。
金額必須是純數字。如果訊息完全不像記帳(例如「你好」),輸出:{"item": null, "amount": 0, "category": "其他"}

使用者訊息:{{ $json.message.text }}

已記帳:{{ $json.item }} ${{ $json.amount }}({{ $json.category }})✅

⚠️ 流程出錯:{{ $json.workflow.name }}
節點:{{ $json.execution.lastNodeExecuted }}
錯誤:{{ $json.execution.error.message }}
詳情:{{ $json.execution.url }}

curl -X POST "https://你的n8n網址/webhook/你的路徑" \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Token: 你的長隨機密鑰" \
  -d '{"item": "測試", "amount": 1}'

順帶一提:Make 怎麼做同一件事

這套觀念完全通用於 Make:它的門鈴叫 Custom webhook 模組,免費方案就能用,貼網址、收資料的流程幾乎一樣,回應則用 Webhook response 模組。差別在帳單:webhook 進來之後的每一個模組都各吃一格 credit,像記帳 bot 這種「trigger + AI + 寫表 + 回覆」的四步流程,免費版 1,000 credits 一個月只夠跑 250 筆。低量玩玩沒問題;量一大或步驟一多,就回到第 1 課的結論——複雜多步驟流程,n8n 按 execution 計費划算得多。

常見坑

坑 1:打 Test URL 得到 404

{"code":404,"message":"The requested webhook \"POST xxx\" is not registered."}

Test URL 只在你按下 Execute workflow、節點進入等待狀態時活著。這個錯誤的意思是「現在沒人在門後等」:通常是你忘了按 Execute、或它已經收過一次請求跑完熄火了。回編輯器再按一次 Execute workflow,趁等待狀態時再打。另外檢查 Method 有沒有對上——節點設 POST 你卻用瀏覽器打開網址(那是 GET),一樣 404。

坑 2:上線後 webhook 沒反應,畫布也不動

三連檢查:(1)外部服務填的是不是 Production URL?測試完忘記把 Test URL 換掉是超高頻失誤,Test URL 平常是死的。(2)workflow 右上角是不是 Active?沒開等於沒營業。(3)你是不是在等畫布動?Production 執行不會顯示在畫布上,去左側 Executions 頁看,有紀錄就是有進來。還有一個隱藏版:改完流程要存檔,Production 跑的是存檔的版本,不是你畫布上沒存的那份。

坑 3:Respond to Webhook 沒作用,回應永遠是罐頭訊息

症狀:明明加了 Respond to Webhook 節點,呼叫方拿到的還是 {"message":"Workflow was started"};或 n8n 跳出警告 Respond to Webhook node not correctly configured / no Webhook node found in workflow。原因:Webhook 節點的 Respond 參數還停在預設值。點開 Webhook 節點,把 Respond 改成 Using 'Respond to Webhook' Node,兩個節點要配對設定才會生效。另外注意呼叫方的等待上限:如果流程要跑很久(例如 AI 生成 30 秒),對方可能等到 timeout,這種情況改成「先立刻回 200 說收到了,結果後續用別的管道送」比較穩。

坑 4:自架 n8n 接 Telegram 失敗

Bad Request: bad webhook: An HTTPS URL must be provided for webhook

Telegram 只肯把訊息推到 HTTPS 網址,你的 http://localhost:5678 它拒收。兩條路:長期方案是照第 3 課的自架路線把 n8n 掛在有網域 + HTTPS 的 VPS 上(Caddy 或 Nginx + Let's Encrypt,一次搞定終身受用);快速測試方案是用 ngrok 之類的隧道工具給本機一個臨時 HTTPS 網址,再把 n8n 的 WEBHOOK_URL 環境變數設成那個網址重啟。隧道網址每次重開都會變,只適合開發測試,別拿來營運。

坑 5:Google Sheets 節點突然 401 / 403

跑了幾週的流程某天開始狂錯 401 Unauthorized 或 403 Forbidden。最常見原因:Google OAuth 授權過期或被撤銷(改過 Google 密碼、太久沒用都可能觸發)。去 n8n 左側 Credentials,找到 Google Sheets 那組,點 Reconnect 重新走一次授權就好。403 的另一個可能是表格權限:確認你授權的 Google 帳號真的有那份試算表的編輯權,尤其是用公司帳號、個人帳號來回切換的人。這種錯誤正是 Error Workflow 的主場——你會在它壞掉的第一分鐘收到 Telegram 通知,而不是月底對帳才發現漏了三週。

作業

1. 基本題:把課堂的 Webhook + Respond to Webhook 流程做出來,用 curl 或 Hoppscotch 打通,截圖 OUTPUT 面板裡你送進去的資料。
2. 主線題:完整做出 Telegram 記帳 bot(Trigger → AI 解析 → Google Sheets → 回覆),切成 Active 之後連續記帳三天。第三天打開試算表,你會對「自動化」三個字有全新的體感。
3. 防線題:建好 Error Workflow 並掛到記帳 bot 上,然後故意弄壞它一次(把 Google Sheets 的 credential 暫時刪掉再傳一筆),確認手機真的收到錯誤通知,再修回來。
4. 挑戰題:找一個你真實在用、支援 webhook 的服務(Tally、Stripe、GitHub、Notion⋯⋯),把它的事件接進 n8n,做任何一件對你有用的事。

下一課預告

到目前為止,你的每條流程都是你畫好的軌道:資料進來、照固定步驟走、輸出結果。但有些任務沒辦法事先畫軌道——「幫我看這封客訴信,該退款就退款、該道歉就道歉、搞不定就轉真人」,每一步該做什麼,要看情況現場判斷。第 7 課進入 AI Agent 模式:讓 AI 自己決定呼叫哪些工具、走哪條路,n8n 的 AI Agent 節點和 Make 在 2025 年推出的 AI Agents 都會講。同時,agent 每一步都在燒 token,所以最後一課也會做成本控管總整理:整個課程用到的每種計費(execution、credit、token)怎麼估、怎麼省,幫你把這門課學的東西變成一套養得起的系統。