甚麼是配送 API？以及它在 2027 年如何運作
物流 API 是一種軟件介面，讓應用程式可以與承運商、物流平台、市集或物流服務交換物流資訊。整合系統不再要求用戶在獨立的控制面板中手動輸入貨件詳情，而是可以發送資料、接收回應、建立或取得物流資訊，並自動更新訂單流程。到了 2027 年，這個詞仍然會描述系統之間的連接，但具體功能將取決於供應商：部分物流 API 專注於運費和標籤，其他則專注於追蹤、配送事件、地址資料或退貨。
對電子商務企業而言，實際價值並不在於 API 本身，而在於更連貫的物流流程：減少重複輸入資料、更快速的營運交接、更清晰的貨件狀態，以及更好地控制訂單發出後客戶所看到的內容。
物流 API 可以做甚麼？
物流 API 透過結構化的請求和回應，將應用程式連接至與物流相關的服務。應用程式可以是電子商務店面、訂單管理系統、倉庫平台、企業資源規劃系統、客戶服務工具或自訂內部應用程式。
典型請求包含訂單參考編號、寄件地點、目的地、包裹尺寸、包裹重量、服務偏好及承運商資料等資訊。接收服務會驗證請求，並以機器可讀格式（通常是 JSON）返回資料。回應可能包含可用的物流服務、追蹤號碼、標籤參考編號、貨件識別碼，或解釋請求無法完成原因的錯誤訊息。
「物流 API」是一個廣泛的概念。在選擇供應商之前，請先確定你實際需要以下哪些功能：
- 運費比較：根據寄件地、目的地、包裹詳情及其他規則，請求可用服務和物流價格。
- 建立貨件：向承運商或物流平台發送貨件資料，並接收貨件記錄。
- 產生標籤：在供應商支援此功能的情況下，建立可列印或可電子使用的物流標籤。
- 追蹤：請求最新貨件狀態，或訂閱狀態更新。
- 配送事件：在承運商或追蹤供應商提供相關事件時，接收收件、運輸中、異常、派送中或已送達等里程碑。
- 地址服務：在所選供應商提供相關能力時，驗證、標準化或檢查地址。
- 退貨：在整合包括退貨功能時，建立退貨貨件、退貨標籤或退貨狀態更新。
這些功能通常會分開銷售。即使標籤和運費由其他系統處理，追蹤 API 仍然可以發揮作用。相反，標籤 API 可能可以建立貨件，但未必能提供電子商務團隊所需的購買後體驗。
物流 API 如何運作
1. 企業定義工作流程
在建立任何技術連接之前，企業需要決定哪個事件應觸發 API 請求。例如，當購物者輸入配送地址時，網店可能會請求物流價格。當訂單獲准進行包裝後，履行系統可能會建立標籤。面向客戶的追蹤頁面可能會在儲存追蹤號碼後請求貨件事件。
這項決定很重要，因為同一張訂單可能會經過多個系統。整合方案應為每項操作指定清晰的負責方，並為每個欄位指定可靠的資料來源。訂單系統可能負責訂單編號，倉庫系統可能負責包裹尺寸，而承運商或追蹤供應商可能負責貨件事件。
2. 應用程式進行身份驗證
大多數物流 API 都要求進行身份驗證。供應商可能會發出 API 金鑰、存取權杖或其他憑證。應用程式會在請求中發送該憑證，以便服務識別帳戶並套用適當的權限。
憑證應儲存在安全伺服器上，而不是暴露於瀏覽器程式碼或流動應用程式檔案中。存取權應限制在需要使用的功能和環境。為測試和正式環境使用不同憑證，有助於控制變更和調查錯誤。
3. 應用程式發送結構化請求
請求通常使用 GET 或 POST 等 HTTP 方法，並包括 URL、身份驗證資料、標頭和主體。主體包含端點所需的貨件資料。追蹤請求可能包括追蹤號碼和承運商識別碼。標籤請求可能需要寄件人、收件人、包裹、服務和海關資料。
資料質素是整合的重要部分。缺少郵政編碼、無效的國家代碼、不支援的服務、不正確的重量單位或不匹配的承運商識別碼，都可能產生錯誤或無法使用的結果。實作方案應在發送資料前進行驗證，並記錄支援所需的請求參考編號，同時避免不必要地記錄敏感資料。
4. 服務驗證並處理請求
供應商會檢查請求格式是否正確，以及帳戶是否獲授權執行所要求的操作。之後，供應商可能會查詢承運商、將回應映射至自己的資料模型、套用帳戶設定，或以非同步方式處理請求。
並非所有回應都會即時返回。供應商可能返回已完成的結果、已接受的請求或錯誤。如果初始請求後仍在繼續處理，應用程式可能需要輪詢結果，或稍後接收 webhook 通知。應根據文件確定支援哪種模式；整合方案不應假設每個端點都以同步方式運作。
5. 應用程式處理回應
成功回應可能包括運費清單、標籤資料、貨件 ID、追蹤號碼或追蹤事件。應用程式會儲存所需欄位，並將其傳遞至工作流程的下一部分。例如，倉庫系統可能會將追蹤號碼儲存至訂單，而客戶通知服務則使用同一號碼建立追蹤連結。
錯誤處理同樣重要。正式環境的整合方案應區分無效輸入、身份驗證失敗、供應商暫時出現問題、承運商拒絕、速率限制回應，以及貨件沒有新的追蹤事件等情況。以相同方式重試所有錯誤，可能會建立重複貨件或產生不必要的流量。
6. 同步貨件更新
追蹤資訊並不總是一個單一的最終答案。貨件狀態可能會隨時間變化，而不同承運商可能使用不同的事件名稱、時間戳記、地點和異常描述。追蹤整合方案可以定期請求更新，或在新資訊可用時接收 webhook。
企業應定義如何處理重複事件、延遲事件、順序錯亂事件、互相衝突的時間戳記，以及停止接收更新的貨件。企業亦應決定向客戶顯示哪個狀態，以及哪些內部事件會觸發客戶服務或營運行動。
物流 API 與追蹤 API 的分別
追蹤 API 是物流 API 的一種類型，但兩者並不可互換。更廣泛的物流 API 可能支援運費、建立貨件、標籤和追蹤。追蹤 API 主要用於取得或分發貨件狀態資訊。
| API 類型 | 典型輸入 | 典型輸出 | 常見負責方 |
|---|---|---|---|
| 運費 API | 寄件地、目的地、包裹詳情 | 可用服務和運費 | 結帳或物流營運 |
| 標籤 API | 貨件、地址、包裹和服務資料 | 標籤資料、貨件參考編號，以及通常包括 追蹤號碼 | 履行或倉庫營運 |
| 追蹤 API | 追蹤號碼，以及在需要時提供承運商 | 貨件狀態和事件歷史 | 客戶體驗、支援或營運 |
| 退貨 API | 訂單、退貨、地址和包裹資料 | 退貨授權、標籤或狀態 | 客戶服務或逆向物流 |
不同供應商的界線各有不同。請務必查看端點文件，而不要只根據產品名稱選擇產品。
電子商務團隊如何使用物流 API
電子商務企業可能會在訂單生命週期的多個階段使用物流 API：
- 結帳：店面使用結帳時可取得的目的地和包裹資料，請求配送選項或運費。
- 訂單分配：訂單系統向倉庫、承運商或物流平台發送履行資料。
- 發貨：履行流程建立或記錄貨件，並將追蹤號碼與訂單關聯。
- 購買後通訊：企業使用貨件事件更新訂單頁面、發送通知，或將異常轉交支援人員。
- 配送分析：營運團隊使用事件資料識別反覆出現的延誤、承運商問題，或履行與配送之間的差距。
- 退貨：獨立或連接的流程建立退貨貨件，並追蹤其退回商戶或處理設施的動向。
對於多承運商營運，追蹤 API 可以減少為每個承運商維護獨立客戶連接的需要。17TRACK 為開發者整合提供 Tracking API，其文件說明了可用的整合流程和端點。企業在選擇將其用於正式環境之前，應確認支援的承運商、事件欄位、身份驗證方法、使用限制和商業條款。
追蹤 API 也可以位於承運商網絡與訂單管理系統之間。這種架構可以簡化應用程式層，但會增加另一項依賴。企業仍然需要負責正確映射狀態、監控資料質素，以及向客戶解釋承運商更新可能會延遲或不完整。
選擇物流 API 前需要檢查甚麼
功能匹配度
列出所需的確切操作：運費、標籤、追蹤、webhook、地址驗證、海關資料、退貨或報告。擅長追蹤的供應商未必適合購買標籤，而特定承運商 API 亦未必能支援多承運商工作流程。
承運商和地理範圍匹配度
檢查 API 是否支援企業使用的承運商、國家、服務類型和運送方向。應根據實際運輸路線和包裹類型驗證覆蓋範圍，而不是根據全球支援的一般聲稱作出推斷。對於跨境物流，請檢查整合方案如何處理海關資料、本地派送合作夥伴，以及交接後的事件。
資料模型和事件質素
將 API 返回的欄位與店面、支援團隊、分析系統和倉庫所需的欄位進行比較。注意事件時間戳記、地點資料、異常代碼、派送證明、預計配送資料和狀態歷史。如果所需欄位沒有記錄在文件中，應將其視為測試期間需要確認的事項。
可靠性和營運控制
檢視身份驗證、速率限制、逾時、重試指引、webhook 安全性、冪等性、版本控制、沙盒存取和事故通訊。了解當承運商暫時無法使用，或同一事件被傳送多次時，整合方案應如何運作。
商業和合規要求
定價可能取決於供應商、端點、貨件量、承運商帳戶或合約。不要只根據 API 呼叫估算總成本。應包括開發、監控、支援、承運商費用、資料儲存，以及處理失敗或重複請求的成本。法律和私隱審查應涵蓋客戶地址、聯絡資料、貨件資料、資料保留，以及與企業相關的資料傳輸。
2027 年實作檢查清單
物流 API 的技術原則不會僅因日曆進入 2027 年而改變。然而，端點、承運商支援、定價、身份驗證要求和資料欄位都可能發生變化。專案開始時，請使用供應商目前的文件和測試環境。
- 定義觸發每個 API 請求的業務事件。
- 為訂單、包裹、追蹤和客戶狀態資料分配負責方。
- 在開發前映射單位、國家代碼、承運商代碼、服務名稱和時區。
- 為本地、跨境、多包裹、地址錯誤、已取消、已退回和延誤貨件設定測試案例。
- 在供應商支援冪等機制的情況下，讓建立操作具備冪等性。
- 儲存供應商參考編號和請求 ID，以便核對和支援。
- 安全地處理重複及順序錯亂的追蹤事件。
- 為身份驗證錯誤、失敗率上升、webhook 延遲和異常貨件建立量設定警報。
- 為供應商或承運商停機記錄備用流程。
- 在上線前及 API 發生重大變更後，再次檢視供應商文件。
因此，最好的物流 API 未必是功能清單最長的 API，而是其文件所述功能、承運商覆蓋範圍、資料質素、可靠性控制和商業模式都符合企業必須運作的工作流程。小型零售商可能只需要追蹤和客戶通知，而大型履行營運可能需要運費選擇、標籤建立、多包裹處理、退貨和詳細核對。應將這些視為不同的整合問題，而不要假設一個 API 可以解決所有問題。
常見問題
物流 API 是否等同於承運商 API？
不是。承運商 API 由特定承運商提供或與其連接，通常會公開該承運商的服務。物流 API 可以連接一個承運商、數個承運商，或將多個來源的資訊標準化的物流平台。實際覆蓋範圍和功能取決於供應商。
物流 API 可以建立標籤嗎？
部分可以，但並非全部。建立標籤通常需要貨件、地址、包裹和服務資料，並可能需要承運商帳戶或計費安排。請確認所選產品是否包括標籤產生功能，以及支援的承運商和服務是否符合企業工作流程。
追蹤 API 會改變貨件的實際位置嗎？
不會。追蹤 API 會報告或分發由承運商或物流資料來源提供的貨件資訊，但不會控制包裹的實際移動。如果承運商尚未掃描物品或延遲更新，API 可能沒有新的事件可返回。
小型電子商務企業應否建立物流 API 整合？
這取決於所需的工作流程和可用的技術資源。如果企業只需要一個簡單的承運商連接，現有的電子商務或物流應用程式可能更實際。當企業需要現有工具無法提供的特定承運商組合、訂單系統、追蹤體驗或自動化功能時，自訂整合會更具吸引力。
選擇物流 API 的第一步是甚麼？
列出系統必須自動化的確切決策和更新。然後根據這些要求比較供應商，包括承運商覆蓋範圍、支援的端點、事件欄位、身份驗證、限制、測試工具、支援、定價和備用程序。使用真實工作流程情境進行小型概念驗證，可以揭示功能清單無法顯示的缺口。
