雲端方程式 Cloud F1 F1

n8n 核心

n8n API 請求與 Webhook｜8 分鐘最速入門

· 約 14 分鐘閱讀 · Alex Hsieh

更新於 2026年2月11日

n8n API 請求與 Webhook

📥 工作流 JSON 下載：GitHub 範例庫 ｜ 💬 社群討論：Skool 雲端方程式 Cloud F1

專業導讀

OK，我們先來講解什麼是 API 請求。很多人問我：「Alex，我想用 n8n 串接外部服務，但 API 到底是什麼？Webhook 又是什麼？兩個有什麼差別？」這大概是我在 Skool 社群裡被問最多的問題了。

其實 API 和 Webhook 這兩個概念沒有你想的那麼難。我在影片裡面用了一個很生活化的比喻 — 麥當勞點餐。你想像今天是一個用戶，你可能是個手機或電腦，你對遠端伺服器提出一個請求，它給你回應，把一個圖片、一個網站回應給你看。就像你在麥當勞的點餐機按下「我要大麥克」，用 LINE Pay 付款，麥當勞的後台會確認你要大麥克、要不要點大薯條、要不要可樂，確認完訂單給你一個號碼說 OK 你點的好了。這就是所謂的 API 的請求跟回應。

在 n8n 裡面，HTTP Request 節點負責「打電話」（主動發 API 請求），Webhook 節點負責「接電話」（被動接收通知）。搞懂這兩個節點，你就能串接市面上 90% 以上的服務了。

你將學到

  • API 的核心概念與 RESTful 架構（用人話解釋）
  • n8n HTTP Request 節點的完整設定方式
  • GET / POST / PUT / DELETE 四種常用請求方法的差異與實戰
  • Webhook Trigger 節點的運作原理與使用場景
  • 認證方式（API Key、Bearer Token、OAuth 2.0）的選擇與設定
  • 實戰範例：串接天氣 API 和接收 GitHub Webhook

什麼是 API 和 Webhook？

API 的全名是應用程式介面，叫做 Application Programming Interface，是程式 A 跟程式 B 做溝通時提出的正式要求。Webhook 則是由伺服器主動發動即時資料到指定 URL 的機制，常用來自動通知或觸發後續的動作。兩者搭配使用，就能實現幾乎所有的系統整合場景。

我用麥當勞跟 Uber 的比喻來解釋：

  • API 就像你在麥當勞點餐 — 你主動跟櫃檯說「我要一個大麥克」，櫃檯幫你新增一個訂單說 Alex 要大麥克，然後做好給你。你不點，就不會有東西來。
  • Webhook 就像你搭 Uber — 你叫車以後，Uber 司機到了載客地點才通知你。你不用一直問「到了沒？到了沒？」，司機到了再跟你說。車子到了再通知你，這樣的機制就叫 Webhook，幫你省下不斷查詢的麻煩。

在技術上，我們用很多的 API，最常見的就是 RESTful API。截至 2026 年，REST 仍然是最主流的 API 風格，雖然 GraphQL 在部分場景越來越受歡迎，但在 n8n 的生態系裡面，絕大多數的整合還是走 REST。

如果你是第一次接觸 n8n，建議先看 n8n 完整入門教學 了解基本操作，再回來學 API 和 Webhook 會更順。

💡 Alex 的觀察

HTTP Request 和 Webhook 這兩個節點，我認為是 n8n 裡面最重要、也是 CP 值最高的節點。為什麼？因為 n8n 內建的整合節點（像 Slack、Google Sheets、Notion）其實底層都是在呼叫 API，只是幫你把介面做好了而已。

但問題是，n8n 不可能幫你做好所有服務的整合節點。當你碰到一個 n8n 沒有內建支援的服務，你唯一的選擇就是用 HTTP Request 節點自己串。所以我常跟學員說：「學會 HTTP Request，你就能串接全世界。」

這就是很像核電廠，你把電廠先打好，你的民生設施就會 OK。HTTP Request 和 Webhook 就是你的「電廠」，學會了之後，不管什麼服務都能串。

不過我要老實說，API 串接最難的部分不是 n8n 的設定，而是看懂外部服務的 API 文件。有些服務的文件寫得很清楚（像 Stripe、GitHub），有些就確實不太行（不點名了）。我的建議是，一開始先找文件寫得好的服務來練手，像是 OpenWeatherMap 或 JSONPlaceholder，熟練之後再挑戰複雜的 API。

另外一點，n8n 2.x 版本（2026 年最新版）在 HTTP Request 節點加入了更好的錯誤提示和 Response 預覽功能，除錯比以前方便很多。如果你還在用舊版本，真的建議升級。

🔧 HTTP Request 節點完整教學

HTTP 方法速覽

在開始之前，先搞清楚四種最常用的 HTTP 方法：

我在影片裡面用麥當勞點餐來做整理，讓大家更好理解：

方法用途麥當勞比喻常見場景
GET查資料看菜單裡面有什麼，大麥克 A 套餐。你拿資料但不動資料本身，不會把大麥克的套餐改掉查詢天氣、取得使用者資料
POST建立新資料跟櫃檯說「我要一個大麥克的套餐」，它就新增一筆資料到系統建立新訂單、發送訊息
PUT完整更新資料你改變主意了，整個訂單 can 掉都不要，我要麥克雞塊餐取代原本的。整份蓋掉更新個人資料、修改設定
PATCH部分更新資料我原本的大麥克加大薯。只改部分，不是整個換掉局部修改設定
DELETE刪除資料完蛋了，忘記已經買晚餐了，不好意思幫我取消，整個刪除現有的資料刪除訂單、移除資料

90% 的情況你只會用到 GET 和 POST。先把這兩個搞熟，其他的碰到再學就好，不用想太多。

API 請求的完整結構

我在影片裡面也做了完整的結構整理。一個 API 請求會有這些組成部分：

  • 方法（Method）：用 POST 就像點一個大麥克的訂單
  • URL：你的對象是誰，就是櫃檯員
  • Header（請求標頭）：補充說明資料，像會員卡、甜心卡。有甜心卡就說 OK 有甜心卡，買 A 送 B 兩個 50
  • Body（主體）：你要送出什麼資訊 — 大麥克、中可樂、去冰
  • Query Parameters（查詢參數）：URL 後面的問號之後的條件，比如只看漢堡類的。注意：看到問號就代表後面是查詢參數
  • Path Parameters（路徑參數）：URL 裡面的變數來指定特定資源，比如訂單編號 123，或像去路易莎問你手機尾碼 661 來找哪一筆訂單

Step 1：建立 HTTP Request 節點（Health Check Demo）

我在影片裡面示範了一個服務在線情況的確認。用戶發出一個 RESTful API GET 的請求，服務器就會回一個 JSON 檔說 OK 狀態是 OK 的。這是一個最簡單的 HTTP Request 示範 — 我用 GET 方法、放上 URL、沒有任何的認證、沒有任何的 Authentication，沒有像要出示甜心卡，直接點 Test Workflow 就收到回應了。然後我還把這個請求的結果放到試算表裡面記錄，類似一個網站的健康檢查，每一天做一次確認。

打開 n8n，新增一個 HTTP Request 節點。你會看到幾個關鍵欄位：

  • Method：選擇 HTTP 方法（GET / POST / PUT / DELETE）
  • URL：API 端點的完整網址
  • Authentication：認證方式
  • Headers：額外的請求標頭
  • Body：請求內容（POST / PUT 需要）
  • Query Parameters：URL 查詢參數（GET 常用）

Step 2：實戰範例 — 串接天氣 API

我們用 OpenWeatherMap 這個免費的天氣 API 來做第一個練習。

首先，到 OpenWeatherMap 註冊一個免費帳號，拿到 API Key。

然後在 n8n 的 HTTP Request 節點這樣設定：

{
  "method": "GET",
  "url": "https://api.openweathermap.org/data/2.5/weather",
  "queryParameters": {
    "q": "Taipei",
    "appid": "你的 API Key",
    "units": "metric",
    "lang": "zh_tw"
  }
}

執行後，你會收到一個 JSON 回應，裡面包含台北的即時天氣資料：溫度、濕度、天氣描述等等。

回應會長這樣：

{
  "weather": [{ "description": "晴天" }],
  "main": {
    "temp": 28.5,
    "humidity": 65
  },
  "name": "Taipei"
}

接下來你可以把這個資料接到 Slack 或 LINE 通知節點，就做出了一個「每天早上自動報天氣」的工作流。

Step 3：POST 請求 — 送出資料

POST 跟 GET 的差別在於，你需要在 Body 裡面帶資料。比如要用某個 API 新增一筆資料：

{
  "method": "POST",
  "url": "https://api.example.com/contacts",
  "headers": {
    "Content-Type": "application/json",
    "Authorization": "Bearer 你的 Token"
  },
  "body": {
    "name": "王小明",
    "email": "ming@example.com",
    "source": "n8n automation"
  }
}

這邊要特別注意 Content-Type 這個 Header，大多數 API 要求你帶 application/json，告訴它你送的是 JSON 格式。n8n 在大部分情況下會自動幫你加，但如果碰到問題，手動加上去就對了。

Step 4：認證方式設定

API 認證是最多人卡關的地方。以下是四種常見方式：

API Key（最簡單）

有些服務只要在 Header 或 URL 參數裡帶一組 Key 就好：

Header: X-API-Key: your-api-key-here
或
URL: https://api.example.com/data?api_key=your-key

在 n8n 裡面，你可以用 Generic Credential 的 Header Auth 來設定，這樣 API Key 不會直接寫在工作流裡面，比較安全。

Bearer Token

很多 API 用 Bearer Token 認證：

Header: Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

n8n 有內建的 Header Auth credential type，選 Bearer 就好。

OAuth 2.0（最安全但最複雜）

Google、Facebook、GitHub 等大型服務都用 OAuth 2.0。OAuth 的流程比較複雜，需要設定 Client ID、Client Secret、Redirect URI 等等。好消息是 n8n 幫你處理了大部分的複雜度，你只需要在 Credentials 裡面填入對應的資訊，然後按「Connect」按鈕就能完成授權。詳細的 OAuth 設定步驟可以參考 Google OAuth 設定教學。

Basic Auth

比較老的 API 會用 Basic Auth，就是帶 username 和 password：

Header: Authorization: Basic base64(username:password)

n8n 有內建的 Basic Auth credential type，填帳密就好，n8n 會自動幫你做 Base64 編碼。

🔧 Webhook Trigger 完整教學

什麼是 Webhook Trigger？

Webhook Trigger 是 n8n 裡面的一個觸發節點。當你啟動一個包含 Webhook Trigger 的工作流，n8n 會產生一個 URL。任何外部服務只要對這個 URL 發送 HTTP 請求，就會觸發你的工作流。

簡單來說：HTTP Request 是你主動出擊，Webhook 是你被動守株待兔。兩個方向剛好相反，但都是 API 通訊的一部分。

Webhook 的兩種模式

在 n8n 裡面，Webhook 有兩種模式：

模式URL 特性用途
測試模式（Test）每次都會變開發除錯
生產模式（Production）固定不變正式使用

重點來了：你在 n8n 編輯器裡面按「Listen for Test Event」時，用的是測試 URL。當你把工作流啟動（Activate）後，用的才是生產 URL。這兩個 URL 不一樣，很多新手在這裡搞混。

實戰範例 — 接收 GitHub Webhook

假設你想要在有人對你的 GitHub repo 發 Pull Request 時，自動收到 Slack 通知。

Step 1：在 n8n 新增一個 Webhook Trigger 節點，設定如下：

HTTP Method: POST
Path: github-webhook（自訂路徑）
Authentication: Header Auth（使用 GitHub 的 Secret）
Response Mode: Last Node（等整個工作流跑完再回應）

Step 2：啟動工作流，複製生產模式的 Webhook URL，格式大概是：

https://你的n8n.com/webhook/github-webhook

Step 3：到 GitHub repo 的 Settings > Webhooks，新增一個 Webhook：

  • Payload URL：填你的 n8n Webhook URL
  • Content type：application/json
  • Secret：跟 n8n 裡面設定的一樣
  • Events：選 Pull requests

這樣每次有人開 PR，GitHub 就會主動打你的 Webhook URL，n8n 就會收到事件資料，然後你可以接 Slack 節點發通知。

Webhook 安全性

Webhook URL 是公開的，任何人只要知道這個 URL 就能觸發你的工作流。所以安全性很重要：

  1. 使用 Authentication — 設定 Header Auth 或 Basic Auth，只有帶正確認證資訊的請求才會被處理
  2. 驗證來源 IP — 有些服務（像 GitHub、Stripe）會公布他們的 IP 範圍，你可以在 n8n 前面加一層 IP 白名單
  3. 使用 HMAC 簽名驗證 — GitHub 和 Stripe 都支援 HMAC 簽名，可以驗證請求確實來自該服務
  4. 不要用太簡單的路徑 — 像 /webhook/test 這種很容易被猜到，建議用有意義但不容易被猜到的路徑

想了解更多 n8n 的安全與錯誤處理最佳實踐，可以參考 n8n 錯誤處理教學。

📊 API 請求 vs Webhook 比較

比較維度HTTP Request（API）Webhook Trigger
方向n8n 主動發請求外部主動推送到 n8n
觸發方式排程 / 手動 / 其他節點外部事件驅動
即時性取決於輪詢頻率即時（事件發生就推送）
資源消耗持續輪詢消耗資源按需觸發，省資源
設定複雜度較低（填 URL 就好）較高（需要外部服務配合）
適用場景定時抓資料、主動操作即時通知、事件回應
n8n 節點HTTP RequestWebhook Trigger
偵錯難度低（直接看回應）中（需要觸發事件）

我的觀察：如果你不確定該用哪個，先問自己一個問題 —「資料是我要去拿，還是別人會主動給我？」如果是你要去拿，用 HTTP Request；如果是別人會給你，用 Webhook。

✅ 重點整理

  1. API 是系統之間交換資料的介面，HTTP Request 節點讓你的 n8n 主動向外部服務請求資料
  2. Webhook 是事件驅動的被動接收機制，外部服務在特定事件發生時主動推送資料到 n8n
  3. 四種 HTTP 方法：GET（取得）、POST（新增）、PUT（更新）、DELETE（刪除），先學好 GET 和 POST 就夠用 90% 的場景
  4. 認證方式選擇：API Key 最簡單，OAuth 2.0 最安全但設定較複雜，依服務要求選用
  5. Webhook 有測試和生產兩種模式，URL 不同，正式使用一定要用生產模式的 URL
  6. Webhook 安全性很重要，務必設定認證、考慮 IP 白名單和 HMAC 簽名驗證
  7. HTTP Request 是 n8n 的萬用節點，學會了就能串接任何有提供 API 的服務

❓ FAQ

Q1：API 認證怎麼選？API Key、Bearer Token、OAuth 2.0 差在哪？

這取決於你要串接的服務支援哪種方式。簡單排序的話：API Key 最簡單，把 Key 放在 Header 或 URL 參數就好；Bearer Token 稍微安全一點，通常是 API Key 的進階版；OAuth 2.0 最安全，適合需要存取使用者個人資料的場景（像 Google、Facebook）。我的建議是，服務支援什麼就用什麼，如果有多種選擇，優先用 OAuth 2.0。在 n8n 裡面，不管哪種方式都是在 Credentials 設定裡處理，流程大同小異。

Q2：HTTP Request 收到錯誤怎麼處理？常見的狀態碼代表什麼意思？

最常見的錯誤狀態碼：401 表示認證失敗（API Key 或 Token 過期了）、403 表示沒有權限、404 表示 URL 或資源不存在、429 表示請求太頻繁被限速、500 表示對方伺服器出問題。在 n8n 裡面，建議開啟「Retry on Fail」功能，設定重試 3 次，每次間隔 1 秒。對於 429 限速，可以在工作流裡加入 Wait 節點，降低請求頻率。更完整的錯誤處理策略可以看 n8n 錯誤處理教學。

Q3：Webhook URL 啟動後會變嗎？測試跟正式環境有什麼不同？

測試模式的 URL 每次按「Listen for Test Event」都可能改變，而且只在你主動監聽時才有效。生產模式的 URL 是固定的，只要工作流是啟動狀態就會持續監聽。重點是：你在 GitHub、Stripe 等外部服務設定的 Webhook URL，一定要用生產模式的。很多新手用測試 URL 設定到外部服務，結果一關掉編輯器就收不到了，這是最常見的坑。另外，如果你有自訂域名，生產 URL 會用你的域名，比較好看也比較穩定。

Q4：n8n 的 HTTP Request 可以串接 AI 相關的 API 嗎？比如 OpenAI？

完全可以，而且這是 2026 年最熱門的用法。用 HTTP Request 串接 OpenAI API 的方式：Method 設為 POST，URL 填 https://api.openai.com/v1/chat/completions，Header 帶 Authorization: Bearer sk-你的key，Body 放 JSON 格式的 prompt。不過如果你只是要用 OpenAI，n8n 有內建的 OpenAI 節點，用那個更方便。HTTP Request 的優勢是在串接 n8n 還沒有內建節點的 AI 服務，比如一些新出的開源模型 API。想了解更多 AI Agent 的整合方式，可以看 AI Agent 完整指南。

Q5：一個工作流裡面可以同時用 HTTP Request 和 Webhook 嗎？

可以，而且這是很常見的組合。經典模式是：Webhook Trigger 接收外部事件（比如使用者提交表單），然後用 HTTP Request 去打其他 API 做後續處理（比如查資料庫、呼叫 AI、發通知）。舉個例子：Stripe 付款完成 → Webhook 收到通知 → HTTP Request 查詢訂單詳情 → HTTP Request 呼叫 Notion API 建立客戶資料 → Slack 通知團隊。這樣一條工作流就搞定了整個付款後流程。學會這套模式，你的 n8n 自動化能力就更上一層了。更多自動化靈感可以看 n8n 自動化完整指南。

🎯 下一步行動

🎓 想更有系統地學會這些技巧？ 到 AI 職場工作術（雲端方程式 Cloud F1 旗艦課程） 看看完整的實作路徑。

API 和 Webhook 是 n8n 自動化的基礎功力。先求大概懂，再開始用，最後才能做成功。我建議你先用免費的天氣 API 練習 HTTP Request，再找一個支援 Webhook 的服務（GitHub 最推薦，文件超清楚）練習 Webhook Trigger。

不用一次學完，慢慢來比較快。你的 AI 實力又變強囉！

想看完整的操作示範，直接看影片最快：

有問題歡迎在下面留言，或到 Skool 社群裡面討論。希望這篇對你有幫助！

🔗 相關資源

本文改編自 YouTube 影片 EP20，由 Alex Hsieh 撰寫。最後更新：2026-02-11

想把這篇學到的用進日常工作？

「AI 職場工作術」課程把這類實戰經驗整理成一步步的教學，帶你系統化練出跟 AI 協作的產能。

看 AI 職場工作術課程 →

本文作者：Alex Hsieh，SRE / DevOps 背景出身，現為企業 AI 導入顧問，也是「AI 相談室」課程講師。專注把 AI 自動化真正落地到企業日常流程，而不是停留在 Demo。

目錄
  1. 專業導讀
  2. 你將學到
  3. 什麼是 API 和 Webhook？
  4. 💡 Alex 的觀察
  5. 🔧 HTTP Request 節點完整教學
  6. HTTP 方法速覽
  7. API 請求的完整結構
  8. Step 1：建立 HTTP Request 節點（Health Check Demo）
  9. Step 2：實戰範例 — 串接天氣 API
  10. Step 3：POST 請求 — 送出資料
  11. Step 4：認證方式設定
  12. 🔧 Webhook Trigger 完整教學
  13. 什麼是 Webhook Trigger？
  14. Webhook 的兩種模式
  15. 實戰範例 — 接收 GitHub Webhook
  16. Webhook 安全性
  17. 📊 API 請求 vs Webhook 比較
  18. ✅ 重點整理
  19. ❓ FAQ
  20. Q1：API 認證怎麼選？API Key、Bearer Token、OAuth 2.0 差在哪？
  21. Q2：HTTP Request 收到錯誤怎麼處理？常見的狀態碼代表什麼意思？
  22. Q3：Webhook URL 啟動後會變嗎？測試跟正式環境有什麼不同？
  23. Q4：n8n 的 HTTP Request 可以串接 AI 相關的 API 嗎？比如 OpenAI？
  24. Q5：一個工作流裡面可以同時用 HTTP Request 和 Webhook 嗎？
  25. 🎯 下一步行動
  26. 🔗 相關資源

相關文章