昨天第一次使用 n8n 的 HTTP Request Node 呼叫 API。
我們做出的流程是：
Manual Trigger → HTTP Request → API → 取得 JSON
甚至還可以把取得的資料繼續交給 AI：
HTTP Request → AI → Google Sheets
不過昨天使用的是公開測試 API，不需要登入，也不需要提供任何身分資訊。
但真正開始使用其他服務的 API 時，通常不會這麼簡單。
例如：
AI API
天氣 API
Google 服務
Notion
GitHub
各種公司自己的系統
很多服務都會先問一件事：
「你是誰？你有權限使用這個 API 嗎？」
所以今天就來認識 API 串接很常遇到的：
Authentication（驗證）
假設一個付費 AI API 完全沒有驗證機制。
任何人只要知道 API 網址，就可以一直送 Request。
結果可能造成：
API 被大量濫用
無法知道是誰發出的 Request
使用額度無法管理
私人資料可能被未授權的人取得
所以很多 API 都需要先確認使用者的身分或權限。
概念大概是：
n8n
↓
帶著驗證資訊
↓
API
↓
檢查權限
↓
驗證成功
↓
回傳資料
這個「確認身分或權限」的過程，就是今天要認識的 Authentication。
第一個最常看到的就是：
API Key
可以先把 API Key 想成服務發給開發者的一組「使用憑證」。
例如：
API_KEY = abc123xxxxxxxx
當 n8n 呼叫 API 時，就需要把這組資訊一起送出去。
API 收到 Request 後，就可以確認：
這個 Request 是誰發出的？
這組 Key 有沒有權限？
還有沒有使用額度？
如果驗證成功，才會回傳資料。
回到昨天使用的 HTTP Request Node。
昨天因為使用公開 API，所以 Authentication 可以不設定。
但很多需要驗證的 API，會要求我們提供不同形式的 Credentials。
圖 1 HTTP Request Node 中與 Authentication 相關的設定
這時候我才發現：
不是所有 API 的驗證方式都一樣。
所以不能看到 API Key 就隨便找一個地方貼上。
真正要看的是：
這個 API 的官方文件要求怎麼傳。
不同 API 可能會要求不同方式。
例如某些 API 可能要求放在 Header：
Authorization: Bearer YOUR_TOKEN
也有 API 可能使用像：
X-API-Key: YOUR_API_KEY
還有些服務可能會透過 Query Parameter 或其他方式處理驗證。
所以實際串接 API 時，第一步不是猜設定，而是先查看該服務的 API Documentation。
昨天 HTTP Request 主要注意的是：
URL
GET
Response
今天又多認識一個東西：
Header
可以先簡單把 Header 理解成 Request 附帶的一些額外資訊。
例如：
Request
│
├── URL
├── Method
├── Headers
└── Body
其中 Header 可能包含：
Authorization
Content-Type
API Key
例如：
Authorization: Bearer YOUR_TOKEN
就是把驗證資訊放在 HTTP Header 裡。
圖 2 HTTP Request 中的 Header 設定位置
除了 API Key，我也常看到：
Token
例如：
Access Token
Bearer Token
API Key 和 Token 都可能被用來協助驗證或授權，但實際用途、產生方式、有效期限和權限管理會依服務而不同。
所以目前不用硬把它們當成完全相同的東西。
今天先記得：
看到 API Key、Token、Access Token 時，都不要直接公開。
這點非常重要。
有些 API 會要求：
Authorization: Bearer YOUR_TOKEN
例如：
Authorization: Bearer abc123456
這代表 Request 會帶著 Token 去存取 API。
概念上：
n8n
↓
HTTP Request
↓
Authorization
↓
Bearer Token
↓
API
API 確認 Token 有效後，才允許存取。
如果沒有帶 Token，或 Token 不正確，就可能收到像：
401 Unauthorized
如果身分已確認、但沒有存取某個資源的權限，也可能遇到：
403 Forbidden
假設取得一組 API Key：
abc123456789
最直接的方法可能是把它貼進 HTTP Request。
但如果之後要截圖、分享 Workflow，甚至把設定交給別人，這組 Key 就可能不小心一起被公開。
所以在 n8n 裡，能使用 Credentials 或適合的驗證設定時，應該優先把敏感的驗證資訊放在專門管理憑證的位置，而不是散落在每個 Node 的文字欄位裡。
概念上比較像：
HTTP Request
↓
Credentials
↓
安全保存驗證資訊
而不是：
HTTP Request
↓
直接把密鑰寫得到處都是
圖 3 使用 n8n Credentials 管理 API 驗證資訊
截圖之前一定要再次確認畫面上沒有顯示真正的 Key 或 Token。
今天其實不一定要真的申請付費 API。
也可以把重點放在理解：
驗證失敗會發生什麼事？
假設某個測試環境要求 Token，但提供了錯誤的驗證資訊。
API 就可能拒絕 Request。
例如：
HTTP Request
↓
錯誤 Token
↓
API 驗證失敗
↓
401 Unauthorized
這又跟 Day 18 的除錯連起來。
看到 HTTP Request 出錯時，就可以開始判斷：
404 → 資源或網址可能有問題
401 → 驗證資訊可能有問題
403 → 可能沒有操作這個資源的權限
5xx → API 服務端可能發生問題
實際原因仍然要看 API 回傳的錯誤內容與官方文件。
今天查資料時還看到兩個很像的單字：
Authentication
Authorization
一開始真的很容易搞混。
我目前把它們簡單理解成：
Authentication：
「你是誰？」
確認使用者或系統的身分。
Authorization：
「你可以做什麼？」
確認這個身分有哪些權限。
例如：
登入成功
↓
Authentication ✓
想刪除資料
↓
檢查是否有刪除權限
↓
Authorization
所以：
有成功驗證身分，不代表什麼事情都可以做。
這也是為什麼 API 會有不同的權限設定。
做到這裡，我才發現其實前面早就碰過 Authentication。
之前把 AI 接進 n8n 時，需要先設定相關的 Credentials。
當時比較像是：
「照著設定把它連起來。」
現在才比較理解背後的概念：
n8n
↓
Credentials
↓
驗證資訊
↓
AI Service
↓
驗證成功
↓
使用模型
所以 Credentials 不只是「設定帳號」而已。
它其實也是 n8n 與外部服務建立授權連線的重要部分。
今天我覺得最重要的反而不是怎麼貼 API Key。
而是：
不要把 API Key 洩漏出去。
尤其我現在會把操作過程寫成鐵人賽文章，又會放很多截圖。
所以之後截圖時要特別檢查：
API Key
Access Token
Password
Client Secret
Credentials
Webhook 中不適合公開的資訊
如果畫面上真的有，就先遮掉再上傳。
而且範例裡也不要使用真正的 Key。
可以改成：
YOUR_API_KEY
或：
************
今天其實不用做很複雜的 Workflow。
重點放在 HTTP Request 的驗證設定就好：
Manual Trigger
↓
HTTP Request
↓
Authentication
↓
External API
↓
Response
如果想接回昨天：
Manual Trigger
↓
HTTP Request + Authentication
↓
API Data
↓
AI
↓
Google Sheets
這樣就可以看出 Authentication 在整個流程中的位置。
圖 4 加入 API Authentication 概念後的 HTTP Request Workflow
昨天學會「怎麼呼叫 API」，今天則進一步理解：
不是知道 API 網址，就代表可以直接使用。
很多服務都會要求驗證資訊。
今天主要認識了：
API Key：API 常見的存取憑證形式之一
Token：另一種常見的存取憑證
Authentication：確認身分
Authorization：確認權限
Credentials：在 n8n 中集中管理外部服務連線資訊的重要方式
我覺得今天最大的收穫不是學會某一個 Node，而是開始理解之前很多「為什麼要設定 Credentials」的原因。
從 Day 20 開始，n8n 已經不只是自己內部的 Workflow，而是開始真的跟外部系統交換資料。
下一個問題就是：
既然 API 可以取得外部資料，那能不能讓 Workflow 每天自己去抓資料，完全不用我按 Execute？
前面學過的 Schedule Trigger 終於可以再次派上用場。
iThome鐵人賽
看影片追技術