當你在 n8n 的世界裡徜徉時，一定會不斷遇到一個詞：API。無論是設定節點的憑證 (Credentials)，還是使用萬能的 HTTP Request 節點，它都如影隨形。你可能隱約知道它和「串接」、「資料」有關，但又說不出個所以然。
當我剛開始玩 n8n 時，看到「API」這個詞也覺得有點距離感，感覺是工程師才需要懂的東西。但後來我發現，搞懂 API 的基本概念，對於 n8n 使用者來說，就像是打通了任督二脈，能讓你從「只會用現成節點」進化到「能串接任何服務」的境界。
這篇文章就是為你寫的「極簡白話文 API 指南」。我會用一個你絕對聽得懂的「餐廳服務生」比喻，讓你秒懂 API 的運作原理，以及它在你的 n8n 工作流程中到底扮演了什麼關鍵角色。
什麼是 API？把它想像成「餐廳服務生」就對了
忘掉那些複雜的技術名詞吧！API (Application Programming Interface，應用程式介面) 的核心概念，其實就是一位訓練有素的「餐廳服務生」。
讓我們來看看這個場景：
- 你 (n8n 工作流程): 你是一位想點餐的顧客。你的需求是「我要一份牛排，五分熟」。
- 廚房 (外部服務，如 Google Sheets / 中央氣象局): 廚房是真正能產出餐點（資料）的地方，但它有自己的運作規則，而且閒人勿進。你不能自己衝進去翻箱倒櫃找食材。
- 服務生 (API): 這位服務生就是你和廚房之間的溝通橋樑。
整個過程是這樣的：
- 你看著「菜單」點餐： 你不能對服務生說些無關緊要的話，必須按照「菜單」上提供的品項和規格（例如：五分熟、加蘑菇醬）來點餐。這份菜單，就是 API 的「規格文件 (Documentation)」，它詳細規定了你「可以要求什麼」以及「該用什麼格式要求」。
- 服務生傳遞訂單給廚房： 服務生（API）把你格式化的訂單（我們稱為「請求 Request」）送進廚房。
- 廚房按訂單做菜： 廚房（外部服務）根據訂單內容，開始備料、烹飪（處理資料）。
- 服務生把餐點送回給你： 廚房完成後，服務生（API）再把熱騰騰的牛排（我們稱為「回應 Response」）端到你的桌上。
所以，API 就是一個定義好的溝通管道與規則，讓不同的軟體服務（例如 n8n 和 Google Sheets）之間，可以在不需要知道對方內部複雜運作的情況下，有效率地交換資料和命令。
API 的三個關鍵元素：n8n 使用者視角
了解了服務生的比喻後，我們把這個概念對應到你在 n8n 操作介面上看到的真實元素。一個完整的 API 互動，通常包含這三樣東西：
1. 請求 (Request)：你向服務生下的訂單
這是你的 n8n 節點告訴外部服務「要做什麼事」。一份清楚的訂單包含了：
- 方法 (Method): 你想做什麼動作？最常見的有：
GET：取得資料（例如：從 Google Sheets 讀取 A1 儲存格的內容）。POST：新增一筆資料（例如：在 Notion 資料庫新增一頁）。PUT/PATCH：更新現有資料。DELETE：刪除一筆資料。
- 端點 (Endpoint): 你要跟哪個服務的哪個部門溝通？這就是那一長串的 URL，例如
https://api.line.me/v2/bot/message/push就是告訴服務生要去 LINE 的「推播訊息部門」。 - 資料 (Data / Body): 你的訂單細節。通常是 JSON 格式，例如
{"to": "使用者ID", "messages": [...]}。
2. 憑證 (Authentication)：你的 VIP 會員卡
服務生怎麼知道你有權限點餐，而且帳要記在誰頭上？這就是「憑證」的作用。你在 n8n 的 Credentials 區塊輸入的 API Key、Bearer Token 或 OAuth2 憑證，就像是你的會員卡。每次下訂單（發送 Request）時，n8n 都會自動附上這張「會員卡」，讓對方服務驗證你的身份，確認你有權限執行這項操作。
3. 回應 (Response)：服務生送回來的餐點
當外部服務處理完你的請求後，會回傳一筆資料，這就是「回應」。在 n8n 中，這筆資料通常會以 JSON 格式顯示在節點的輸出 (Output) 中。這也是為什麼你可以輕鬆地用表達式 {{ $json.body.someValue }} 來取得回應中的特定欄位，因為它已經是一份整理好的、結構化的資料了。
為什麼 API 對 n8n 如此重要？
搞懂了 API，你就搞懂了 n8n 的靈魂。
1. 所有「預設節點」都是打包好的 API 請求 當你使用 n8n 內建的 Google Sheets、Notion 或 Telegram 節點時，你其實正在使用一個「懶人包」。n8n 的開發者已經幫你把 Google Sheets 官方那本厚厚的「菜單」(API 文件) 都讀完，並設計出一個個簡單易懂的欄位。你只要在圖形化介面中填寫儲存格、內容等資訊，n8n 就會在背後幫你自動組合成一個完全符合 Google API 規範的 Request，然後發送出去。
2. 「HTTP Request 節點」是你的萬能 API 工具 那如果 n8n 沒有內建你想串接的服務節點怎麼辦？別擔心！只要那個服務有提供 API（也就是有公開的「菜單」），你就可以使用 HTTP Request 這個萬能節點來跟它溝通。
HTTP Request 節點就像是給你一張空白的點餐單，你可以自己決定 Method、填寫 Endpoint URL、放入 Body Data、並在 Header 中附上憑證。這賦予了 n8n 無限的擴充性，讓你能夠串接世界上任何有 API 的服務。
一個簡單的 n8n 實例：用 API 查詢台灣天氣
讓我們用一個最實際的例子，帶你感受一下 HTTP Request 節點的威力。我們將使用台灣「中央氣象署」的開放資料 API 來查詢天氣。
步驟 1：取得你的 API 金鑰
首先，你需要前往 中央氣象署開放資料平臺 註冊一個帳號，並取得你的 API 授權碼（API Key）。這就是我們前面提到的「會員卡」，完全免費。
步驟 2：閱讀 API 文件 (菜單)
在氣象署的 API 說明頁面，我們可以找到查詢「一般天氣預報」的「菜單」。文件告訴我們：
- Endpoint URL:
https://opendata.cwa.gov.tw/api/v1/rest/datastore/F-C0032-001 - 需要參數:
Authorization=你的API金鑰,locationName=縣市名稱
步驟 3：在 n8n 設定 HTTP Request 節點
- 在 n8n 新增一個
HTTP Request節點。 - Authentication: 選擇
Header Auth。 - Name: 輸入
Authorization。 - Value: 輸入你從氣象署網站取得的 API 金鑰。
- URL: 貼上
https://opendata.cwa.gov.tw/api/v1/rest/datastore/F-C0032-001。 - 在下方的
Query Parameters區塊，新增一個參數：- Name:
locationName - Value:
高雄市
- Name:
步驟 4：執行並查看結果！
按下「Execute Node」，你會看到節點成功執行，並在右邊的 Output 視窗看到一堆 JSON 資料。仔細展開 records -> location -> 0 -> weatherElement，你就能找到包含天氣狀況、最高溫、最低溫等所有你需要的氣象資訊！
你成功了！你剛剛完成了一次最純粹的 API 互動，這代表你已經掌握了 n8n 最核心的串接能力。
結語
API 並不是什麼遙不可及的黑魔法，它就是一套讓軟體之間能夠順暢溝通的「標準語言」和「行為規範」。
對於 n8n 使用者來說，你不需要成為 API 開發專家，但只要理解「服務生」的核心比喻，並掌握 請求 (Request)、憑證 (Authentication)、回應 (Response) 這三個關鍵元素，你就能夠：
- 更深入地理解 n8n 每個節點背後的運作原理。
- 在遇到問題時，能更快地判斷是哪一個環節出錯。
- 最重要的是，你能充滿信心地使用
HTTP Request節點，去挑戰那些 n8n 還沒有內建節點的服務，真正實現「萬物皆可串」的自動化理想。
現在，API 的大門已經為你敞開，快去探索更多可能性吧！
