n8n API 串接觀念與除錯手冊¶
這份筆記專門幫你把 API 串接這件事講清楚，因為多數 n8n 實戰問題，本質上都是 API 問題。
想一想¶
API 可以先想成「系統之間講話的方式」。你平常打開網站、登入、查資料，是人用畫面跟系統互動；API 則是讓 n8n 用固定格式跟系統互動。n8n 的 HTTP Request 節點就像一個代替你發問的人：它帶著網址、方法、身份證明、參數和資料，去問另一個服務，然後把對方回傳的結果交給下一個節點。
初學 API 最容易卡在細節，例如 header、body、token、JSON 格式。但不要一開始就被名詞嚇到。你只要先問四件事：我要對哪個網址發 request？我要讀資料還是寫資料？對方要我怎麼證明身份？回來的資料長什麼樣子？大部分 API 問題都可以沿著這四題排查。n8n 的好處是讓你看得到每一步輸入與輸出，所以出錯時不要亂改，先看 request 送出去什麼，再看 response 回來什麼。
本篇怎麼讀¶
- 學習目標：看懂 API 串接的基本結構，建立穩定的排錯順序
- 先修需求：知道什麼是 Webhook 與 JSON
- 讀完後你應該能：看文件、組 request、理解 response、定位常見錯誤
目錄¶
- 為什麼你一定要會 API
- API 的最小觀念
- HTTP Request 節點怎麼想
- Method、Headers、Body、Auth
- 最常見 API 串接流程
- 錯誤排查與除錯順序
- Webhook 與 API 的差別
- API 學習心法
- Appendix. 測試清單
1. 為什麼你一定要會 API¶
n8n 很多時候只是幫你把 API 用更可視化的方式串起來。
所以真正的關鍵不是「會按哪個 node」，而是： - 你知不知道 API 要怎麼打 - 你看不看得懂 API 回來的 JSON - 你知不知道錯在哪一層
只要你 API 觀念穩，n8n 就會容易很多。
2. API 的最小觀念¶
API 可以理解成系統提供給你的一個入口。
你送一個 request，它回一個 response。
你最少要知道 4 件事： - URL - Method - 要不要認證 - 回傳格式長什麼樣子
例子：
- GET /users/1 可能是取資料
- POST /orders 可能是新增資料
2.1 新手最常混淆的地方¶
很多人以為 API 就是某個平台專屬功能，但其實你每天碰到的很多服務本質上都提供 API。
你可以把它想成： - Webhook：別人把資料送給你 - API Request：你去把資料要回來，或送出去
只要這個分界清楚，你對 n8n 的很多節點理解都會更穩。
3. HTTP Request 節點怎麼想¶
在 n8n 裡，HTTP Request node 不是神秘工具，它只是幫你組出一個 HTTP request。
你要思考的是： - 我要送去哪個 URL - 用哪種 method - 要不要帶 token - 要不要送 body - 回來的 JSON 我怎麼取值
4. Method、Headers、Body、Auth¶
4.1 Method¶
最常見：
- GET：取資料
- POST：新增資料
- PUT / PATCH：更新資料
- DELETE：刪除資料
4.2 Headers¶
常見 header：
Content-Type: application/json
Authorization: Bearer YOUR_TOKEN
4.3 Body¶
當 API 要你送資料時，通常會放在 body。
例如：
{
"name": "Tung",
"email": "tung@example.com"
}
4.4 Authentication¶
最常見幾種： - API Key - Bearer Token - Basic Auth - OAuth
5. 最常見 API 串接流程¶
5.1 讀取資料¶
流程：
- Manual Trigger
- HTTP Request (GET)
- Set
5.2 新增資料¶
流程：
- Webhook
- Set
- HTTP Request (POST)
- Respond to Webhook
5.3 同步資料¶
流程：
- Schedule Trigger
- HTTP Request A
- Set
- HTTP Request B
這類流程的本質，是把一個系統的資料轉給另一個系統。
5.4 真實案例¶
- 每天從商城 API 抓新訂單，再同步到內部系統
- 從 Typeform 收到資料後，送到 CRM API 建立 lead
- 從 Notion 讀資料，再送到 Slack 或 Email 系統
6. 錯誤排查與除錯順序¶
API 出錯時，照這個順序查。
6.1 先看 URL¶
- 打錯 domain
- path 少一段
- query parameter 不對
6.2 再看 Method¶
- 該用
POST卻打成GET - 該用
PATCH卻打成PUT
6.3 再看認證¶
- token 過期
- token 放錯 header
- 忘了
Bearer前綴
6.4 再看 Body¶
- JSON 格式錯誤
- 欄位名稱跟 API 文件不一致
- 少必填欄位
6.5 最後看 Response¶
很多人看到失敗就只說 API 壞了，但其實 response 通常已經告訴你原因。
你要看： - status code - error message - 回來的 JSON
6.6 一個實際排錯例子¶
情境：
你用 HTTP Request 打一個新增訂單 API，結果失敗。
排查順序：
1. 先確認 URL 和 method
2. 再看 header 是否有 Authorization
3. 再看 body 是否少了必要欄位
4. 最後看 response 裡的錯誤訊息
這種流程的價值在於，你不會把所有問題都混在一起猜。
7. Webhook 與 API 的差別¶
這兩個很容易混。
7.1 Webhook¶
是別人打你的入口。
7.2 API Request¶
是你主動去打別人的入口。
7.3 在 n8n 裡的差別¶
Webhooknode：負責收資料HTTP Requestnode：負責送資料
很多 workflow 其實就是：
Webhook 收 -> Set 整理 -> HTTP Request 送出去
8. API 學習心法¶
8.1 不要死背設定畫面¶
先看 API 文件在要求什麼。
8.2 不要同時改太多項¶
先讓最小 request 成功，再慢慢加欄位。
8.3 一定要看回應內容¶
response 才是真相，不是你的猜測。
8.4 真正要練的是這個能力¶
- 看文件
- 組 request
- 看 response
- 修 request
只要這 4 步你做熟，n8n 串 API 會變得很自然。
本篇練習¶
- 找一個公開 API，用
GET打通。 - 寫下它的 URL、method、headers、response 結構。
- 再找一個需要 body 的 API，理解它要求哪些欄位。
- 把 response 整理成
Set節點可直接使用的欄位。
下一篇建議¶
如果你想把 API 串接和 AI 結合，下一步讀 07 n8n + OpenAI 實作範例集。
Appendix. 測試清單¶
每次串 API 前後，檢查： - URL 正確 - Method 正確 - Header 正確 - 認證正確 - Body 正確 - Response 可讀 - 回來的 JSON 已被你整理成下一步可用格式