HTTP Request 節點：碰所有沒官方整合的 API

為什麼要會這個節點

n8n 官方支援 400+ 個節點，包了大部分你聽過的知名 SaaS。但把鏡頭拉遠——全世界有 API 的服務大概有幾十萬個：

• 你們公司自架的內部系統（工單、進銷存、CRM）——n8n 當然不會做
• 台灣本土 SaaS（例如某本土記帳、某本土物流、某本土發票 API）——太小眾
• 剛推出的新服務——n8n 還來不及做節點
• 大家都有但 n8n 剛好沒做的（例如某冷門的 CI/CD）
• 你自己寫的服務、部門內部的 microservice

只要它有一個 REST API（就是網址打進去會回 JSON 那種），你就能用 HTTP Request 節點打。這個節點的地位跟 Code node 一樣，是 n8n 的逃生口——現成節點做不到的，這個節點都能兜出來。

一句話學會這章：看到「n8n 沒這家的節點」不要慌，翻對方 API 文件、開 HTTP Request 節點、填四個欄位、就打通了。

HTTP 呼叫的四要素

不管哪家 API，打一次 HTTP 呼叫都要決定四件事。學過 HTTP 的可以跳過，沒學過的花三分鐘看完就永久受用——

Method（方法）其實就是動詞，講你想對那個 URL 做什麼——

• GET：拿——去讀一份資料，不會改任何東西（例：抓客戶清單）
• POST：建立——新增一筆資料（例：建一個新使用者）
• PUT：整筆覆蓋——用你傳的 body 蓋掉原本那筆
• PATCH：部分更新——只改幾個欄位，其他保留
• DELETE：刪除——一筆走人（例：刪掉那個使用者）

Headers（標頭）是附帶資訊，最常見的兩個：

• Authorization: Bearer <你的 token>——認證你是誰
• Content-Type: application/json——告訴對方「我送 JSON 過去」

Body（本體）只有 POST、PUT、PATCH 才要填——就是你要傳過去的資料，通常是一坨 JSON。GET 跟 DELETE 不帶 body（有些 API 例外，但少見）。

看 API 文件的三個關鍵

拿到一份陌生 API 的文件——不管是 Stripe、Notion、還是你們公司內部系統——你要在文件裡找三件事，其他都是花絮：

1. Endpoint URL（往哪打）

   通常在文件的側欄或表格會列出所有可打的網址，例如 https://api.example.com/v1/users、https://api.example.com/v1/orders/{id}。網址裡的 {id} 這種括號代表要換成實際的值。

2. Method（用什麼動詞）

   每個 endpoint 旁邊會標 GET、POST、PUT、DELETE——就是這個 endpoint 該用什麼 method。同一個 URL 有時候會支援多個 method（例：GET /users 拿清單、POST /users 建新的），要看清楚別搞混。

3. Auth（怎麼認證）

   文件開頭一定會有 Authentication 章節，告訴你這家用哪種認證。常見三種：Header 帶 Bearer Token（多數現代 API）、URL 後面帶 ?api_key=xxx（比較老派）、OAuth 走一輪流程（Google、Facebook 那種）。看清楚是哪種，才知道要怎麼填。

不同家 API 的文件長相不太一樣，但這三件事一定寫得到。找不到就代表文件寫得爛，或是你要去問對方 support。

動手：打第一個 API（GitHub 公開資料）

先用一個不用 auth 的公開 API 熟練節點介面。目標：抓 GitHub 使用者 octocat（吉祥物章魚貓）的公開資料。

1. 在 Canvas 加 HTTP Request 節點

   Canvas 空白處按 + 開節點抽屜，搜尋 http，選 HTTP Request。它會出現在你 workflow 上，左右兩邊都有圓點（跟 Action 節點一樣）。前面如果沒有 Trigger 節點，先加一個 Manual Trigger（給你手動按執行）串起來。

2. Method 選 GET

   節點右邊面板打開，最上面的 Method 下拉選 GET（預設就是 GET，通常不用改）。

3. URL 填 https://api.github.com/users/octocat

   下方 URL 欄位貼入這串網址。這是 GitHub 官方的公開 REST API，抓某使用者的資料。

4. Authentication 保留 None

   因為公開資料不用 auth。真實情況多半要選 Generic Credential Type 或 Predefined Credential Type，這章後面會詳講，第一次先跳過。

5. 按 Execute step

   節點右上角有 Execute step 按鈕（有些版本叫 Test step）。按下去，n8n 會實際打這隻 API。

6. 看右邊 output pane 的 JSON

   幾秒內右邊會出現章魚貓的資料——login: "octocat"、id: 583231、name: "The Octocat"、avatar_url: "..."、public_repos: 8——一整包 JSON。這代表你成功打了一次 API。

7. 下一個節點就能用 {{ $json.login }} 取欄位

   在這個 HTTP Request 後面接一個 Slack 或 Set 節點，訊息欄位打 使用者 {{ $json.login }} 有 {{ $json.public_repos }} 個 repo，跑起來就會替換成實際值。這叫 Expression，第 14 章會專門講。

Authentication 常見三種寫法

公開 API 是少數，實務上多半要 auth。你會遇到的三種寫法對照：

節點裡的 Authentication 下拉有幾個選項：

• None——公開 API 不用 auth
• Predefined Credential Type——n8n 有預設幫你設定好的，選對應的服務就好（例如 OpenAI、Notion、HubSpot）
• Generic Credential Type——自己指定認證方式，下拉出現 Basic Auth、Custom Auth、Digest Auth、Header Auth、OAuth1 API、OAuth2 API、Query Auth 七種（有些版本另有 Simplified Custom Auth）

動手：POST 送 JSON 給 API

GET 是拿，POST 是送。實務上你要「用 n8n 建立一筆資料到別家 SaaS」的時候就用 POST。假設某訊息 API 的 endpoint 是 POST /messages，body 要傳 {"text": "訊息內容", "to": "[email protected]"}——步驟如下：

1. Method 改 POST

   右邊面板最上面 Method 下拉選 POST。選了 POST，下面會多出 Send Body 選項。

2. URL 填 endpoint

   例如 https://api.example.com/v1/messages。這串在對方文件都會告訴你。

3. Authentication 設好

   依對方要求選——多數是 Generic Credential Type → Header Auth，填一組 Authorization: Bearer <你的 token>。

4. Send Body 打勾

   要傳 body 的話，把 Send Body 開關打開。

5. Body Content Type 選 JSON

   會出現 Body Content Type 選單，n8n 提供五個選項：JSON、Form URLencoded、Form-Data、n8n Binary File、Raw。多數現代 API 都用 JSON；上傳檔案的表單用 Form-Data；上傳純二進位（例如 PDF 直傳）用 n8n Binary File；對方要 XML 或自訂 MIME 用 Raw。看對方文件說什麼就選什麼。

6. Specify Body 選 Using JSON，貼入 payload

   會出現一個大文字框，貼進：

   {
     "text": "{{ $json.message }}",
     "to": "[email protected]"
   }

   裡面 {{ $json.message }} 就是 Expression，會抓上一個節點的 message 欄位。要寫死也可以，直接打 "你好"。

7. Execute step 看回應

   按執行。右邊 output pane 會出現對方 API 的回應——通常是 {"id": "msg_xxx", "status": "sent"} 這種確認訊息。如果收到 {"error": "..."}，看 troubleshoot 段。

常見 API pattern 對照表

幾乎每家 REST API 都長類似的樣子——CRUD（Create、Read、Update、Delete）四種操作對應到四個 method。認得這個 pattern，你翻對方文件會快很多：

Query 參數（URL 問號後面那串 ?a=1&b=2）在 HTTP Request 節點裡不用手打，可以用 Send Query Parameters 開關，然後一列一個 Name/Value 填。n8n 會幫你組出正確的 URL，包括 URL encode（例：中文、空白會自動轉義）。

分頁（Pagination）處理

大部分 API 一次不會回全部資料——會限制一次最多回 100 筆（有的 50、有的 25）。你要撈 500 筆客戶，就得連打 5 次，每次拿一頁。這叫分頁（pagination）。

好消息：n8n HTTP Request 節點內建分頁機制，不用自己寫迴圈。步驟：

1. 打開節點的 Pagination 分頁

   節點右邊面板往下滑，找到 Pagination 區塊，把 Pagination Mode 從 Off 改成你要的 mode。

2. 選 mode——依 API 文件說明

   兩種常見：

   • Response Contains Next URL——API 回傳的 JSON 裡有一個 next 或 next_url 欄位，n8n 自動抓下去打
   • Update a Parameter in Each Request——你告訴 n8n 每次要改哪個 query 參數（例：page=1, 2, 3... 或 cursor=xxx）

3. 設 Complete Expression（什麼時候停）

   n8n 用一個布林 Expression 判斷是否停止——欄位叫 Complete Expression，填類似 {{ $response.body.results.length === 0 }}（回空陣列就停）或 {{ !$response.body.next_page }}（沒下一頁就停）。另可設 Limit Pages Fetched 給一個上限頁數當防呆（例：最多 20 頁）。

4. 執行，看 output

   執行後 n8n 會自動連續打幾次，把所有頁的資料合併成一整包 output。下一個節點看到的就是完整的 500 筆，不用你關心分頁。

官方分頁文件寫得很詳細（各種 pattern 都有範例）：docs.n8n.io/code/cookbook/http-node/pagination。

建 credential 給 HTTP Request 節點用

如果你會反覆用同一組 API key 打同一家 SaaS 的多個 endpoint（例：先 GET 客戶清單、再對每個客戶 POST 訊息、再 DELETE 過期的），與其每個節點都貼一次 token，不如把 token 存成 credential，多個節點共用。

1. 左側 Credentials → Create Credential

   左側主導覽選 Credentials，右上角按 Create Credential（或第一次建立的引導按鈕）。

2. 搜尋 Header Auth

   credential 類型清單搜 header，選 Header Auth（舊版介面顯示為 HTTP Header Auth，同一個東西）。這是最通用的一種（Bearer Token、X-API-Key 都用這個）。

3. Name 填 Authorization，Value 填 Bearer <你的 token>

   Name 是 header 欄位名稱，Value 是欄位值。整組存下來給這組 credential 取個好記的名字，例如 MyCompany CRM Bearer。

4. 回節點，Authentication 選 Generic Credential Type → Header Auth → 選剛建的那組

   之後這個節點打的每一次 request 都會自動帶那個 header。多個節點都選同一組 credential，改 token 只要改一個地方。

節點其他常用選項一次認

節點下拉最下面有 Add Option 按鈕，可以打開更多進階選項。這幾個你早晚會遇到：

常見錯誤排除

API 打不通時，錯誤訊息通常是 HTTP status code——認得幾個常見的省很多時間：

1. 401 Unauthorized（沒認證或 token 錯）

   Auth 沒設對或 token 過期。先在 Postman、Insomnia、或 curl 打通一次再回來對照——把能跑的 curl 完全複製，n8n 節點的 Method、URL、Header 一格一格填成一樣。這樣就能孤立問題（是 n8n 設定問題、還是 token/URL 問題）。

2. 403 Forbidden（有登入但沒權限）

   Token 對了，但這個 endpoint 你沒權限打。看對方 API 文件的 scope 或 role 段——通常要開特定權限（例：OpenAI 要有 read 或 write scope、Slack 要 chat:write）。重新產一組有正確權限的 token。

3. 404 Not Found（URL 錯或資料不存在）

   URL 拼錯、少寫 /v1/、path 裡的 {id} 值錯（那筆資料不存在）。仔細比對文件的 URL；用 Expression 動態組 URL 時特別容易多一斜線或少一斜線。

4. 429 Too Many Requests（打太快）

   對方 API 有 rate limit（例：每分鐘 60 次）你超過了。三個解法：（1）節點 Options → Batching 設 interval；（2）前面加 Wait 節點降速；（3）節點打開 Retry on Fail 加上 Retry Wait（第 17 章詳講）。

5. 500 / 502 / 503（對方伺服器爛掉）

   不是你的問題，對方 API 掛了。開 Retry on Fail（重試 3 次，每次等 5 秒）通常就會過。持續 500 就是對方真的壞了，去 twitter 搜對方 status page。

6. 200 但回 HTML 不是 JSON

   你的 URL 打錯了——可能是被 302 導向到登入頁或錯誤頁。看 output 是不是一堆 <html>、<body> tag。仔細對 URL、確認 auth 有設好、確認 API base URL 正確。有時候 https vs http 也會導。

7. 成功但 body 是空的

   看看 status code 是不是 204 No Content——這是「成功但沒東西回」，正常。DELETE 常常回 204。或是 API 設計就這樣（成功不回 body）。要看是否成功，把 Options → Response → Full Response 打開，就能看到 status code 判斷。

8. SSL 憑證錯誤

   公司內部 API 常常用自簽 SSL 憑證。到節點 Options → Add Option → Ignore SSL Issues (Insecure) 打開能繞過驗證。只有內部服務才這樣做——打公網 API 千萬不要關 SSL 驗證，會被中間人攻擊。

常見問題