軟體之間進行溝通的結構化方式。在 AI 領域中，這通常表示將請求（您的提示）傳送至服務供應商的伺服器，並接收回應（模型的輸出結果）。透過 HTTPS 的 REST API 是標準做法。
每一家 AI 提供商 — Anthropic、Google、Mistral — 都透過 API 提供其模型。如果你所構建的 AI 應用超出聊天視窗的範疇，你就正在使用 API。
在機械層面上，一個 AI API 呼叫只不過是一個 HTTP 請求 — 几乎總是向 HTTPS 端點發送一個 JSON 主體的 POST 請求。你傳送你的提示、系統指令、模型參數（如溫度和最大 token 數），而服務提供者則會回傳一個包含模型輸出的 JSON 回應。目前大多數服務提供者都遵循 OpenAI 設定的模式：一個 /v1/chat/completions 風格的端點，接受包含 role/content 對的訊息陣列。Anthropic 的 Messages API 在結構上稍有不同，但遵循相同的哲學。關鍵要理解的是，這些都是無狀態的呼叫 — 除非你每次明確重新傳送對話歷史，否則伺服器不會記住你之前的請求。
串流是事情變得更有趣的地方。與等待模型完成整個回應（長篇回應可能需要 10-30 秒）不同，大多數 AI API 支援伺服器傳送事件（Server-Sent Events，SSE）。伺服器會在生成時逐個 token 發送回應，因此你的用戶幾乎立即就能看到文字。這就是為什麼即使完整回應需要一些時間，ChatGPT 和 Claude 還是感覺這麼即時 — 你正在即時觀看模型「思考」的過程。正確實現串流意味著處理部分 JSON 區塊、管理連線逾時，並在串流中斷時優雅地恢復。
驗證方式在不同服務提供者之間有所不同，但通常屬於兩種模式之一：將簡單的 API 金鑰作為授權標頭中的 Bearer token 進行傳送，或在企業環境中使用更複雜的 OAuth 流程。Anthropic 使用 x-api-key 標頭，OpenAI 使用 Authorization: Bearer sk-...，而 Google Cloud 則需要服務帳號憑證。如果你正在處理多個服務提供者 — 這在大多數生產系統中都是常見情況 — 你很快就會發現「OpenAI 相容」其實是一個光譜。Together AI、Groq 和 Mistral 等提供者大多遵循 OpenAI 的架構，但錯誤處理、參數支援和回應格式化的邊界情況才是整合工作的真正所在。
有一個誤解值得澄清：即使 REST API 主導市場，它們並不是唯一選擇。一些提供者提供 gRPC 端點以實現更低的通訊開銷，而基於 WebSocket 的 API 在即時語音和串流應用場景中變得越來越常見。例如，ElevenLabs 的語音 API 使用 WebSockets 進行雙向音訊串流。但對於文字輸入文字輸出的 LLM 推論，REST 搭配 SSE 串流仍是標準，而且這在短時間內不太可能改變 — 相較於模型生成 token 所花費的時間，HTTP 的開銷幾乎可以忽略不計。