在整合AI供應商時，端點就是關鍵所在。每個供應商都有自己獨特的架構方式，這也正是Zubnet等平台存在的原因—為混亂的狀況建立統一標準。
端點（endpoint）是伺服器上的一個 URL 路徑，用於接收特定類型的請求並回應特定類型的結果。在 AI API 中，最常見的端點是對話完成端點 — 在 OpenAI 的架構中為 POST /v1/chat/completions，而在 Anthropic 則為 POST /v1/messages。但現代 AI 提供商會公開多樣化的端點，不僅限於對話功能，例如 /v1/embeddings 用於將文字轉換為向量，/v1/images/generations 用於圖像生成，/v1/audio/transcriptions 用於語音轉文字，以及 /v1/models 用於列出可用模型。每個端點都期望不同的請求參數，並回傳不同格式的結果。
實際的挑戰在於，所謂「與 OpenAI 相容」的端點僅是近似相容。Groq、Together AI 和 Fireworks 都宣稱支援 OpenAI 相容性，對基本的對話完成請求來說運作良好。但深入細節後會發現差異：有些不支援結構化輸出的 response_format 參數，有些處理工具/函數呼叫的方式不同，錯誤回應格式也存在廣泛差異。Anthropic 基本上不嘗試與 OpenAI 相容 — 他們的 Messages API 使用完全不同的結構，content 是一個區塊陣列，而非純文字字串。當你建立一個在多個提供商之間路由的系統時，這些差異往往會佔據大部分的工程時間。
版本控制是另一個重要的維度。提供商會隨著時間演進其端點，並可能發生破壞性的變更。OpenAI 使用基於日期的模型版本（例如 gpt-4-0125-preview），但端點路徑本身保持穩定。Anthropic 則在請求中加入版本標頭（anthropic-version: 2023-06-01），用以決定請求/回應的結構。Google 的 Vertex AI 則在 URL 路徑中使用版本前綴。當提供商廢棄某個端點版本時，通常會有幾個月的預告，但如果你不關注他們的變更日誌，可能會某天早上發現整合突然中斷。
基礎 URL 也值得特別提及，因為它們不像你預期的那樣直觀。Anthropic 的 API 位於 api.anthropic.com，但 OpenAI 提供 api.openai.com 用於直接存取，並為 Azure OpenAI Service 部署提供獨立的基礎 URL。某些提供商會根據資料主權合規性設立區域端點 — 例如 europe-west1-aiplatform.googleapis.com 的請求會留在歐盟境內。對於透過推理平台（如 HuggingFace 的 Inference API）路由的提供商，基礎 URL 是平台本身（router.huggingface.co），而模型識別碼則放在路徑或標頭中。理解這種架構非常重要，因為延遲、資料主權與計費都可能取決於你實際呼叫的端點。