什麼是 API？來看實際操作示範

幾乎每個 2026 年的 AI 工具註冊流程，都會冒出同樣三個字母：API。ChatGPT、圖像生成器、網頁爬蟲、CRM 整合——這個詞到處都是；但大多數說明文章一開頭還是那套老掉牙的餐廳比喻，卻從來沒真的讓您看過 API 長什麼樣。這篇文章不一樣。您往下滑幾個段落，就會看到真實的 API 請求、真實的回應，也會理解為什麼您的銷售團隊、營運流程和電商系統，每天都離不開 API。

我在 花了很多時間思考，怎麼把技術概念講給商務團隊聽——也就是那些不寫程式、卻很需要懂工具之間怎麼互相溝通的人。所以我整理了研究資料、測試了即時 API 呼叫，寫成這份指南，讓您真正看到「給我看，不只是告訴我」的內容，而不是大多數 API 說明文章略過的部分。銷售業務、行銷經理、電商營運——這篇會講到您真的用得到的重點。

什麼是 API？用白話文來說

API（Application Programming Interface，應用程式介面）是一組規則，讓一套軟體可以向另一套軟體索取資料或要求執行動作，並取得結構化的回應。

換句話說，它就是兩個系統之間的正式接點。您不會存取整個資料庫、整個應用程式，或背後的整家公司；您只能存取 API 對外開放的部分，依照它要求的格式送出請求，然後拿回它承諾提供的內容。 、 和 的說法都很一致：API 是一種機制或契約，讓軟體元件依據明確的規則與協定進行溝通。

可以把它想成得來速窗口。您用特定格式下單（某個餐點、份量，或許還加點客製化），然後您拿到您要的東西——完全不用走進廚房。菜單就是 API 文件，窗口就是端點（endpoint），收據就是回應（response）。

但比喻再好，也只能幫您理解一部分。下面直接看 API 呼叫到底長什麼樣子。

真實的 API 請求與回應長什麼樣

現在就把這個網址貼到瀏覽器：

1https://api.agify.io?name=michael

您剛剛送出了一個 GET 請求 給 Agify API，請它預測與名字「michael」相關的年齡。您會拿到這樣的結果（JSON 回應）：

1{
2  "count": 304886,
3  "name": "michael",
4  "age": 61
5}

就這樣。您剛剛完成了一次 API 呼叫。沒有程式碼、沒有終端機，也不用安裝任何東西。請求就是那個網址（加上一個參數），回應則是瀏覽器以文字顯示的結構化資料。每一個 API 都遵循這個基本原則：送出結構化請求，回傳結構化回應。

API 不是什麼

API 不是資料庫。它是放在資料庫（或服務、模型）前面的受控存取層。

API 不是網站。網站是設計給人類閱讀和點擊的；API 是設計給軟體讀取與處理的——它回傳的是結構化資料（通常是 JSON），不是視覺化頁面。

API 不是駭客入侵。它只會存取提供者刻意開放的資料與功能。

為什麼商務團隊應該關心 API？

如果您在銷售、營運、行銷或電商團隊，您也許從來沒親手寫過 API 請求。但您每天都在使用與 API 連動的軟體——而懂得這個概念，會讓您在評估工具、設計自動化流程，以及和開發團隊溝通時更有優勢。

API 其實早就融入您的日常工作中了——以下就是常見場景：

實際效果就是：減少人工輸入、降低錯誤率，原本要花幾小時的流程，現在幾秒就能完成。 發現，現在有 的受訪者直接從 API 創造營收，高於前一年的 28%。而且有 的人表示自己是「API-first」，也就是先設計與測試 API，再開發依賴它們的應用程式。

下次您在評估某個 SaaS 工具時，先問一個問題：它有 API 嗎？能提供什麼？光是這一題，就可能幫您省下好幾個月的整合麻煩。

API 怎麼運作？請求—回應循環一次看懂

這個模式永遠差不多：

1. **您（client，客戶端）**送出請求——「嘿，給我紐約的天氣。」
2. API收到請求，檢查它是否合法、是否有權限，然後把它轉送到正確的伺服器。
3. 伺服器處理請求——查詢資料庫、執行模型，或執行某個動作。
4. API把回應送回來——以結構化資料（通常是 JSON）加上狀態碼，告訴您發生了什麼事。

可以這樣想像：

客戶端 → 送出請求（方法 + 端點 + 標頭 + 主體）→ API 端點 → 伺服器處理 → API 端點 → 送出回應（狀態碼 + JSON 主體）→ 客戶端

您真的會用到的關鍵術語

來源：、、。

含糊不清的請求通常會被拒絕。有效的請求需要正確的端點、方法、權限與欄位。好的 API 文件，就是告訴您可以問什麼、要怎麼問的操作手冊。

API vs. SDK vs. Webhook vs. Library：差別到底是什麼？

廠商簡報很愛把「API」、「SDK」、「webhook」和「library」混著講，好像它們是同義詞一樣。其實不是。我聽過夠多次這類簡報，知道這種混淆真的很常見。下面這張表，就是我當年最希望有人直接丟給我的版本：

再補充一點脈絡：

• SDK：如果您在做行動應用程式，SDK 會把所有東西都打包給您——API、範例程式碼、文件、工具。除非您在跟開發者合作，不然一般不太會直接接觸到 SDK。
• Library：library 是別人寫好的程式碼，您可以直接拿來放進自己的程式裡用。它可能底層有用到 API，但它是給開發者的工具，不是系統之間的溝通管道。
• Webhook：不是您一直去問 API「付款過了嗎？現在呢？」；webhook 則是換個模式——當事件真的發生時，伺服器主動通知您。您可以把它想成軟體版的推播通知。

到了 2026 年，大家講「API」時，幾乎都是在指 web API——特別是 REST API。只要知道這些相關名詞，您就不會在廠商簡報或和工程團隊的 Slack 訊息裡迷路。

API 的主要類型（以及您什麼時候會遇到它）

按存取層級分類

• 公開（Open）API：任何人都能使用。例：免費天氣 API，或像 這類公開資料 API。
• 私有（Internal）API：只供公司內部使用，用來串接內部系統。例：您的 CRM 跟帳務系統互相溝通。
• 合作夥伴 API：只在合約約定下，開放給特定商業夥伴。例：物流公司把貨運追蹤資料分享給零售商。

按架構分類

來源：、、。

如果您是商務使用者，大多只會接觸 REST API 和 webhook。其他類型了解一下就好，方便和供應商溝通；但 SaaS 文件、Zapier 整合，以及像 Thunderbit 這類工具，預設起點通常都是 REST。

2026 年的 AI API：改變一切的使用情境

早期那種「什麼是 API」文章，常把大家第一次接觸 API 的場景寫成 Google Maps 或 Stripe。但到了 2026 年，事情根本不是這樣。大多數新手第一次看到「API」這個詞，是因為註冊了 ChatGPT、試過圖像生成器，或是在研究 AI 擷取工具。

從技術上看，AI API 的運作方式和其他 API 一樣。您送出請求——一段提示詞、一份文件、一個網址——然後取得結構化輸出。差別在伺服器端：它不是去查資料庫某一列，而是執行模型。

實際例子：

• OpenAI API：送出文字提示 → 回傳 AI 生成的回應。
• 圖像生成 API：送出描述 → 回傳 AI 生成的圖片。
• AI 資料擷取 API：送出雜亂的網頁 → 回傳乾淨、結構化的資料。

Thunderbit 的 Open API 如何把雜亂網頁變成結構化資料

接下來講到我特別有偏好的部分（原因很明顯）。 提供 Open API，能把 AI 驅動的資料擷取能力程式化：

• Distill API：送出網頁 URL → 回傳乾淨的 Markdown，方便分析或接進 AI 流程。很適合內容分析、知識庫建置，或把資料餵給 LLM 工作流程。
• Extract API：先定義 schema（欄位名稱、類型），再送出 URL → AI 會擷取出符合您 schema 的結構化 JSON 資料。

下面是一個簡化範例。假設您把一個雜亂的 Amazon 商品頁 URL 送到 Thunderbit 的 Extract API：

1POST https://api.thunderbit.com/v1/extract
2Authorization: Bearer YOUR_API_TOKEN
3Content-Type: application/json
4{
5  "url": "https://example-store.com/products",
6  "fields": [
7    { "name": "product_name", "type": "text" },
8    { "name": "price", "type": "number" },
9    { "name": "rating", "type": "number" }
10  ]
11}

您會拿到這樣的回應：

1{
2  "status": "success",
3  "data": [
4    { "product_name": "Organic Cotton Tee", "price": 29.99, "rating": 4.7 },
5    { "product_name": "Linen Button Shirt", "price": 54.00, "rating": 4.5 }
6  ]
7}

這份回應可以直接匯入試算表。一次 API 呼叫，就省下好幾小時的人工複製貼上。 用的是同一套 AI 引擎，只是包在無需寫程式的介面裡；而 API 則讓需要大規模自動化的團隊也能直接使用。

想更深入了解 AI 驅動的擷取實務，可以參考我們的文章： 或 。

您的第一個 API 呼叫：動手做的小教學

兩分鐘。不用下載、不用安裝，也不用寫程式。準備好了嗎？

步驟 1：打開瀏覽器

開一個新的瀏覽器分頁。

步驟 2：貼上一個免費 API 網址

把這段複製貼到網址列，然後按 Enter：

1https://api.agify.io?name=michael

您剛剛送出了一個 GET 請求給 Agify API，請它預測與名字「michael」相關的年齡。

步驟 3：一起讀懂 JSON 回應

您應該會看到像這樣的內容：

1{
2  "count": 304886,
3  "name": "michael",
4  "age": 61
5}

• "name" —— 您提供的輸入
• "age" —— API 的預測結果
• "count" —— 它使用了多少資料點

就這樣。您剛剛完成了一次 API 呼叫。

步驟 4：進階一點——試試需要金鑰驗證的 API

接著來試一個更接近真實世界的例子。前往 ，註冊免費帳號，取得 API 金鑰。然後貼上這樣的網址（把 YOUR_KEY 換掉）：

1https://api.openweathermap.org/data/2.5/weather?q=London&appid=YOUR_KEY&units=metric

這次，您需要用 API 金鑰證明自己的身分。這就是 驗證（authentication）——也是大多數真實世界 API 的運作方式。

步驟 5：理解回應碼

當您呼叫 API 時，有時會看到錯誤而不是資料。以下是最常見的狀態碼意思：

來源：。

一張表搞懂 API 安全：金鑰、OAuth 與 JWT

您其實已經不知不覺用了兩種驗證等級：沒有驗證（Agify）和 API 金鑰（天氣）。另外兩種方法，則把整體圖像補完整：

來源：、。

當您貼上那個 Agify 網址時，您用的是無驗證。當您加上天氣 API 金鑰時，您用的是 API 金鑰驗證。當應用程式需要存取您的個人資料時，就會輪到 OAuth 和 JWT 出場——例如您按下「用 Google 登入」的時候。

Thunderbit 的 Chrome 擴充功能使用的是瀏覽器本身已登入的工作階段（抓取時不需要另外輸入 API 金鑰），而 Thunderbit 的 Open API 則使用標準的 Bearer token 驗證。這是同一個產品中，兩種模式並存的實際例子。

如何保護 API 金鑰安全

• 絕對不要把 API 金鑰公開分享出去（不要截圖、不要放在共用文件、不要放到公開儲存庫）。
• 不要把金鑰硬寫進共用文件或試算表。
• 如果您是開發者，請使用環境變數或 secrets manager。
• 定期輪替金鑰；一旦懷疑外洩，立刻更換。

您每天其實都在用的真實 API 範例

您今天午餐前，可能已經用了半打 API，卻完全沒注意到：

• 商業網站上嵌入的 Google Maps：網站使用 Google Maps API 取得並顯示地圖。您看到的是地圖；背後其實是一次 API 呼叫把它抓回來。來源：。
• 「用 Google／Facebook 登入」：基於 OAuth 的 API，讓您不必註冊新帳號就能登入。
• 金流處理（Stripe、PayPal）：您在線上結帳時，API 負責商店與金流供應商之間的付款流程。來源：。
• 天氣 App：您手機的天氣 App 每次開啟時，都會呼叫天氣 API。
• AI 聊天機器人與助理：ChatGPT、Claude 和 AI 擷取工具，都是透過 API 對外提供能力。
• Spotify 的推薦引擎：當 Spotify 推薦播放清單時，背後是 API 在提供曲目資料、使用者偏好與模型預測。
• Thunderbit 的 AI Web Scraper：使用 AI 從，而且現在也提供 Open API，讓團隊能大規模自動化資料擷取。

如何為您的業務需求挑選合適的 API

當您要選 API——或幫您的開發團隊挑選——下面這些 معیار最值得問：

快速比較如下：

發現，企業平均要管理 ，其中 的企業至少管理 500 個 API。這麼多環節，也難怪文件、支援與清楚的定價這麼重要。

API 與自動化資料輸入：概念如何變得實用

當您把 API 對準任何商業流程中最枯燥的部分——資料輸入——事情就開始變得有趣了。

，而 ——這聽起來不高，但如果您的資料集有 10,000 筆，那就是 100 個錯誤。在金融、醫療或電商領域，哪怕只是幾個錯誤，也可能讓成交案卡住，或引發合規問題。

自動化資料輸入系統會把 API 與 OCR、AI 和機器學習結合起來，負責擷取、提取、驗證與匯出資料——不需要人工在分頁之間複製貼上。通常流程如下：

1. 資料擷取：系統從來源讀取資料（網頁、PDF、圖片或表單）。
2. 提取：AI 或 OCR 辨識並抓出相關欄位。
3. 驗證：規則會檢查錯誤、重複或缺漏值。
4. 匯出：乾淨資料流入試算表、CRM、ERP 或資料庫——通常透過 API 完成。

Thunderbit 在這個流程中扮演的是 AI 驅動的擷取層。透過 ，商務使用者可以打開網頁、點擊「AI 建議欄位」，讓 AI 自動判斷該擷取哪些欄位——。資料可以直接匯出到 Excel、Google Sheets、Airtable 或 Notion。若團隊需要大規模自動化，Thunderbit 的 Open API 則把同一套 AI 變成可程式化端點。

想看更貼近實務的自動化資料輸入案例，可以參考我們的文章： 或 。

FAQ

1. API 是什麼的縮寫？

API 是 Application Programming Interface 的縮寫，也就是應用程式介面。它是一組規則，讓兩個軟體程式可以互相溝通——一方提出資料或動作請求，另一方則以結構化格式回應。

2. 使用 API 一定要會寫程式嗎？

不一定。很多 API 都可以從瀏覽器、Postman，或像 Zapier 這類無程式工具直接呼叫。像 Thunderbit 的 Chrome 擴充功能，就是在背後使用 API，但您完全不需要寫任何程式。Open API 則屬於程式化介面，但商務團隊仍然可以透過內部工具或自動化平台來使用。

3. API 和網站是一樣的嗎？

不是。網站是設計給人類閱讀與點擊的；API 是設計給程式讀取的——它回傳的是結構化資料（例如 JSON），不是視覺化網頁。它們常常在同一個網域底下，但用途完全不同。

4. API 是免費的嗎？

有些是（例如公開資料 API）。有些則採用 freemium 模式（免費方案＋付費方案），或按次收費。像 Thunderbit 的 Open API 就是採點數制，並提供免費方案供測試。記得一定要查看每個供應商的定價、速率限制與服務條款。

5. API 金鑰和 OAuth 有什麼差別？

API 金鑰是一串每次請求都要帶上的機密字串——簡單，適合基本存取。OAuth 2.0 則是一種更複雜的流程，使用者會授權應用程式有限權限（像「用 Google 登入」），讓應用程式能存取特定資料，但不會看到使用者密碼。API 金鑰是用來識別應用程式；OAuth 則是授予有範圍限制的使用者權限。

延伸閱讀