接上 n8n:讓訊息流進你的自動化流程

你已經把 LINE 官方帳號開好了,後台導覽也走過一遍。客人掃 QR Code 加進來,傳了一句「請問你們今天有開嗎?」——然後一片靜默。

LINE OA 後台有內建的「自動回應訊息」功能,但它只能對關鍵字回固定文字。客人打「開店時間」你可以回一段話,但客人打「今天幾點?」就漏掉了;更不可能根據庫存查詢、訂單狀態、或客人說話的語氣給出不同答案。LINE OA 的後台就像一台沒插電的電話總機:硬體在、號碼也通,就是接不起來。

這堂課要做的,就是把那條線插上去:把 LINE 傳進來的每一則訊息,透過 Webhook 串進 n8n 的自動化流程。接好這條線,你才能在第 4 課讓 AI 來接電話。

這堂學什麼

• LINE Messaging API 的完整訊息路徑:用戶訊息如何一步步從 LINE 走進你的 n8n 流程
• n8n Webhook 節點的設定方式:取得公開 URL、貼進 LINE Developer Console、通過驗證
• 拆解 LINE 訊息的 JSON 格式:event / message.text / replyToken / source.userId 各是什麼
• 打出第一個 echo bot:用戶說什麼、機器人就回什麼(HTTP Request 呼叫 Reply API)
• Reply API 與 Push API 的本質差異:什麼情況免費、什麼情況消耗推播額度

觀念一:訊息怎麼從 LINE 走進 n8n

先建立正確的系統圖,後面操作才不會搞不清楚自己在哪個環節。

整條鏈路有五個角色:

1. 用戶:在 LINE App 對你的官方帳號傳訊息。這個動作觸發了後續所有事情。
2. LINE Platform:LINE 的伺服器接收到訊息後,把它打包成一個 JSON 格式的「webhook 事件」,然後用 HTTP POST 送到你指定的網址(Webhook URL)。注意這是 LINE 主動推過來,不是你的程式去問 LINE 說「有沒有新訊息?」
3. n8n Webhook 節點:你在 n8n 建一個 Webhook 節點,它會產生一個公開的 HTTPS 網址。你把這個網址貼進 LINE 後台,LINE 以後就把訊息送到這裡。
4. 你的流程:n8n 接到訊息後,你可以做任何事:判斷訊息內容、查資料庫、呼叫 AI——這堂課先做最簡單的 echo bot,把用戶說的話直接回傳。
5. Reply API:把回覆送回去給用戶。用戶看到的那句話,就是從這裡出去的。

關鍵是第 2、3 步的 Webhook 機制:LINE 需要一個公開的 HTTPS 網址才能推訊息給你。所以 n8n 一定要部署在有公開網址的環境(n8n Cloud 或自架且有 HTTPS 的 VPS),你的本機 localhost 收不到。

觀念二:LINE 訊息的 JSON 長什麼樣

LINE 推來的資料是一個 JSON,你的 n8n 節點要從裡面提取需要的欄位。

{
  "destination": "Uxxxxxxxxx",
  "events": [
    {
      "type": "message",
      "message": {
        "type": "text",
        "id": "468789577898262530",
        "text": "你們幾點開門?"
      },
      "source": {
        "type": "user",
        "userId": "Uabc12345def67890"
      },
      "replyToken": "38ef843bde154d9b91c21320ffd17a0f",
      "timestamp": 1720000000000
    }
  ]
}

四個你一定要認識的欄位:

• events[0].type:事件類型。傳文字訊息是 "message",加好友是 "follow",取消追蹤是 "unfollow",按快速回覆按鈕是 "postback"。你的 n8n 流程要先過濾,確認是 "message" 類型才繼續處理。
• events[0].message.text:用戶說的那句話,就在這裡。這是你要丟給 AI 或做關鍵字比對的原始輸入。
• events[0].replyToken:這是你「回覆這則訊息」的門票,只有 30 秒有效期、只能用一次。呼叫 Reply API 時必須帶上它。超過 30 秒或重複使用就會回傳 Invalid reply token。
• events[0].source.userId:傳訊息的用戶 LINE ID。之後用 Push API 主動推訊息,或記錄用戶的互動歷史,都需要這個。

另外注意 events 是一個陣列——理論上 LINE 偶爾會一次推多筆事件,但實務上幾乎都是一筆。

觀念三:Reply API vs Push API,額度怎麼算

這是很多人設計機器人時搞混的地方,先釐清再動手。

LINE OA 的每月訊息額度(2026 年現況,已由多家代理商確認):

重點:這個額度只計算 Push API 的主動推播訊息。用 Reply API 回覆用戶——也就是用戶先說話、你用 replyToken 回應——是完全免費、不佔這個額度的。

結論很清楚:客服機器人回答客人問題,一律用 Reply API。主動推促銷、預約提醒這類不是由用戶訊息觸發的訊息,才用 Push API。這樣一來,免費方案的 200 則額度只會用在你真正「主動出擊」的地方。

手把手實戰

以下用 n8n Cloud 的環境示範。如果你自架 n8n,確認有 HTTPS 公開網址之後步驟完全一樣。

https://你的n8n網址/webhook-test/line-webhook

條件 1: {{ $json.body.events[0].type }} 等於 "message"
條件 2: {{ $json.body.events[0].message.type }} 等於 "text"

{
  "replyToken": "{{ $json.replyToken }}",
  "messages": [
    {
      "type": "text",
      "text": "你說的是:{{ $json.userText }}"
    }
  ]
}

測試一下

你說的是:測試一下

常見坑

接 LINE Webhook + Reply API 的過程中,這五個坑幾乎人人都踩過一次。

坑 1:HTTP 401 Unauthorized — Reply API 回傳「The request body has no reply_token」或直接 401

原因幾乎都是 Channel Access Token 填錯或格式不對。最常見的錯誤是直接把 Token 字串貼進 Header 的 Value 欄位,忘記前面要加 Bearer (有空格)。正確格式:

Authorization: Bearer eyJ0eXAiOiJKV1Qi...

另外注意 Token 的種類:LINE Developer Console 裡有「Short-lived token」(短期)和「Issue」出來的「Channel access token(long-lived)」(長期)。建議用長期的,不用擔心過期問題。

坑 2:Webhook 驗證一直失敗,顯示「Unable to verify the webhook URL」

按下 LINE Console 的 Verify 按鈕但失敗。排查順序:

1. URL 開頭是 https:// 嗎?http 直接拒絕
2. n8n Webhook 節點有在 Listen 狀態嗎?要先按「Listen for Test Event」才有在等
3. URL 路徑完整正確嗎?少一個斜線都不行
4. 如果是本機 n8n,有用 ngrok 之類的工具暴露出去嗎?

坑 3:流程被觸發,但 events[0] 報「Cannot read properties of undefined」

你的 n8n 流程跑起來,但後面的節點說找不到 events[0]。原因是 LINE 會定期對你的 Webhook URL 發送「空陣列」的心跳包確認存活:

{ "destination": "Uxxxxxxxxx", "events": [] }

這個包的 events 是空的,你的 events[0] 當然 undefined。解法:在 IF 節點加一條前置條件:{{ $json.body.events.length > 0 }},空陣列就直接跳過,不往後跑。

坑 4:訊息偶爾不回,Reply API 報「Invalid reply token」

這是 replyToken 的 30 秒限制。如果你的 n8n 流程在那 30 秒內跑不完(例如 AI 節點回應很慢、有等待步驟),replyToken 就過期了。

解法一:先回一句「收到你的問題,我來查一下」(用 replyToken 立刻回),然後繼續跑 AI 邏輯,最後用 Push API 把完整答案推出去。 解法二:優化流程速度,把不必要的等待節點移掉。

注意 replyToken 只能用一次。如果你在測試時把同一個 replyToken 貼到 Postman 試,第二次用就會失敗——這是設計如此,不是 bug。

坑 5:Signature 驗證失敗(如果你有自己加驗簽邏輯)

LINE 每次推 Webhook 都會在 Header 帶上 x-line-signature,這是用你的 Channel Secret(不是 Channel Access Token,是另一個值)做 HMAC-SHA256 簽出來的。如果你打算自己驗簽,有幾個地方容易出錯:

• 先解析 JSON 再驗簽:錯了。HMAC 要對原始 request body(raw bytes)做,JSON.parse() 之後再 stringify 會改變字串,簽名就對不上
• 用錯金鑰:Channel Secret 在 Developer Console 的「Basic settings」頁籤,不是 Messaging API 頁籤的 Token
• 編碼問題:body 必須是 UTF-8,如果你的框架在某個環節轉了編碼,HMAC 就會對不上

n8n 的標準 Webhook 節點目前不內建 LINE 的 Signature 驗簽(需要用 Code 節點自己寫),課程早期練習階段可以先跳過,正式上線前補上。

作業

1. 完整跑一遍這堂課的實戰步驟:在 n8n 建好 Webhook 節點、通過 LINE 的 Verify、傳訊息給自己的 OA、收到 echo 回覆。截圖 LINE 對話視窗那個「你說的是:XXX」的畫面存起來,下一課會在這個基礎上繼續。

2. 改造 echo bot:在 HTTP Request 的 JSON body 裡,把回覆文字改成帶有你店家資訊的問候語,例如:

{
  "replyToken": "{{ $json.replyToken }}",
  "messages": [
    {
      "type": "text",
      "text": "嗨!我是【你的店名】的小助手 🤖\n你說:「{{ $json.userText }}」\n我還在學習中,下次就能給你更好的回答!"
    }
  ]
}

3. 思考題:你的店每天大概會有多少則客人訊息?乘以 30 天,算一下你一個月的 Reply API 呼叫量。這些全部是免費的——反過來,你真正會用到推播額度的場景是什麼?

下一課預告

echo bot 只會鸚鵡學舌,沒有任何實際用途——但你已經打通了最重要的管道。第 4 課要在 Set 節點和 HTTP Request 之間,插入 Claude 或 GPT 的 AI 節點,讓機器人真正「理解」客人說什麼、給出有意義的回答。我們會設計第一版的系統提示詞、讓 AI 知道自己的角色是哪家店的客服、以及怎麼讓回答既有禮貌又不廢話。你的客服機器人,即將開口說人話。