首頁博客比較追蹤 API 與配送 API：你的電子商務技術堆疊需要哪一個（還是兩者都需要）？

追蹤 API 與配送 API：你的電子商務技術堆疊需要哪一個（還是兩者都需要）？

17TRACK

當你的電商技術堆疊需要建立貨件及產生運輸標籤時，請使用shipping API。當系統需要在發貨後追蹤貨件，並將承運商更新轉化為實用的營運資訊或面向客戶的資訊時，請使用tracking API。如果你的軟件必須管理貨件建立及購買後的可見度，便需要這兩種能力，但不一定需要兩個供應商或兩個獨立整合。

Tracking API vs Shipping API Which Does Your Ecommerce Stack

這項決策應由負責履行架構的人作出：通常是與工程團隊合作的電商營運主管。首先確認你的商店、倉庫或履行合作夥伴已經處理哪些工作。加入另一個 API 應該是為了解決特定缺口，而不是重複一個已經運作良好的工作流程。

tracking API 與 shipping API 有甚麼分別？

兩者的區別主要在於每個 API 所執行的工作，而不是產品類別之間的嚴格界線。運輸平台可能包含追蹤端點，而追蹤服務可能提供通知及面向客戶的派送更新工具。與其依賴產品名稱，不如評估已記錄的端點及事件行為。

決策維度Tracking APIShipping API
主要工作取得或接收貨件狀態及追蹤事件。建立貨件並取得標籤及相關運輸文件。
典型輸入追蹤號碼、承運商識別碼，以及任何其他所需的貨件詳情。寄件人及收件人資料、包裹資訊、服務選擇，以及適用的海關資料。
典型輸出貨件狀態、事件歷史，以及其他可用的派送資訊。貨件識別碼、標籤及支援的文件。
主要工作流程派送可見度、異常處理及購買後更新。倉庫發貨及出庫貨件準備。
不要作出的假設取得追蹤資料便包括標籤建立或承運商預約。建立標籤便包括你所需的追蹤深度及通知控制功能。

承運商文件說明了這種分工。FedEx 在其 Ship API documentation 中記錄貨件建立功能，並在其 tracking API documentation 中記錄追蹤功能。這些是不同技術職責的例子，並不代表建議選擇任何特定承運商。

建立貨件不等同於觀察其運送進度

成功的貨件建立回應只表示你的軟件已處理運輸請求，並不能證明承運商已實際接收包裹。同樣地，追蹤號碼可能在追蹤歷史中出現運送記錄之前已經存在。

因此，你的訂單管理系統應區分標籤建立、倉庫交接、承運商接收及派送。將這些全部視為單一的「已發貨」事件，可能會導致過早向客戶發送訊息，並掩蓋實際上尚未離開倉庫的包裹。

選擇能解決目前瓶頸的能力

當發貨是缺失環節時，選擇 shipping API

當你的應用程式必須將訂單資料轉化為貨件時，shipping API 是合適的起點。例如，倉庫團隊需要手動將地址複製到承運商入口網站，或自訂訂單管理系統無法產生標籤。

選擇整合方案前，先定義實際的發貨工作流程。你只需要建立貨件，還是也需要取得運費、取消、提貨請求、海關文件或日終流程？這些功能可能是獨立 API、取決於承運商，或需要額外的帳戶權限。不要假設標示為「shipping API」的產品包含所有運輸操作。

不適合作為唯一方案：只負責建立標籤的整合方案，卻讓你的客戶服務團隊需要逐一查閱承運商網站。它可以解決發貨問題，但派送可見度基本上不會改變。

當貨件建立已經運作時，選擇 tracking API

當標籤已由你的倉庫管理系統、履行合作夥伴、網絡市場或現有運輸整合方案建立，但派送資訊零散時，tracking API 會是更直接的選擇。

在這種情況下，替換標籤工作流程可能增加遷移工作，卻未能解決核心問題。相反，應將上游產生的追蹤號碼連接至可供你的訂單管理系統、支援工具及客戶通訊使用的可見度層。

在這個類別中，17TRACK Tracking API 是相關的整合選項。其官方 API 文件說明追蹤號碼登記及追蹤資料工作流程，包括推送通知。請根據你所需的承運商、貨件類型及應用程式架構評估這些工作流程。這是對追蹤層的考量，並不表示該服務可以取代標籤產生整合。

不適合作為唯一方案：當你的軟件仍然沒有辦法建立其負責發出的貨件時使用 tracking API。追蹤可見度無法解決缺少運輸執行的問題。

當應用程式同時負責發貨及派送可見度時，使用兩者

當你的技術堆疊必須產生標籤，然後維持可靠的貨件進度視圖時，兩種能力都適用。它們可以來自同一個平台、不同服務，或承運商整合方案與追蹤層的組合。

當單一整合方案的運輸及追蹤功能符合你已記錄的要求，且不會迫使你作出不必要的妥協時，應優先選擇單一整合。當現有運輸工作流程值得保留，或追蹤要求與該工作流程所提供的功能有重大差異時，才考慮分開整合。獨立的追蹤供應商不一定更好；它必須證明額外的整合、計費及營運管理責任是值得的。

兩個 API 如何融入電商技術堆疊

實際設計應將訂單、貨件及追蹤事件保留為獨立記錄。一個訂單可能產生多個包裹，而每個包裹可能有自己的追蹤歷史。面向客戶的訂單狀態應根據這些貨件記錄產生，而不是覆寫這些記錄。

  1. 訂單準備好履行。商店或訂單管理系統將所需的履行資料傳送給負責的倉庫。
  2. 運輸工作流程建立貨件。應用程式儲存返回的貨件識別碼、追蹤號碼、承運商、服務及標籤參考資料。
  3. 倉庫完成交接。倉庫確認與承運商接收應保持為可區分的事件。
  4. 追蹤工作流程開始。應用程式按照所選整合方案的要求登記或提交追蹤號碼。
  5. 追蹤更新傳送到應用程式。Webhook、輪詢或受支援的組合會更新貨件記錄。
  6. 業務規則決定下一步。當符合相關條件時，系統會更新面向客戶的狀態、建立營運任務或發送訊息。

例如，使用第三方履行倉庫的商戶可能只需要在自己的軟件中處理第四至第六步。倉庫已經負責建立貨件。自行營運倉庫的商戶則可能需要完整流程。

為每項下游操作指定一名負責人

如果兩個整合方案都提供追蹤更新，請指定哪個系統負責客戶通知及商店中顯示的貨件狀態。否則，客戶可能收到重複訊息，或看到互相矛盾的派送狀態。

你可以保留次要資料以便調查，但不要讓每個來源都能觸發電郵。保留原始承運商事件及你的內部狀態映射，讓支援人員能夠了解系統為何以特定方式對貨件進行分類。

比較營運適配度，而不是功能標籤

確認你實際使用的承運商及服務

承運商支援並非簡單的是非問題。某項服務可能支援某承運商的追蹤，卻不支援該承運商的標籤建立。標籤建立也可能取決於始發國家、承運商帳戶設定或服務資格。

根據你實際的運輸路線建立測試清單。包括本地包裹、國際貨件，以及運輸合作夥伴之間的任何交接。確認每項所需操作：建立貨件、追蹤貨件，或兩者皆要。對你的業務所依賴的服務進行成功測試，比廣泛的覆蓋聲明更有用。

檢查事件含義及資料完整性

對於追蹤，測試首次掃描前、派送異常期間、派送嘗試失敗後及派送完成時的行為。檢查時間戳記是否包含時區資訊，以及原始承運商描述是否仍然可用。

不要將標準化狀態解讀為每個承運商都會提供完全相同的資料。預計派送日期、位置詳情及派送證明資料可能取決於底層承運商及貨件。決定當這些欄位缺失時，你的介面應如何運作。

檢查兩方面的故障恢復

對於運輸，在建立貨件期間發生逾時需要特別注意：即使你的應用程式沒有收到回應，請求也可能已經成功。在盲目重試前，確認供應商支援的重複防止及對賬機制。

對於追蹤，測試重複通知、延遲事件、Webhook 傳送不成功及端點暫時故障。在相關文件中確認驗證、重試行為及恢復選項。設計事件處理流程，確保重播更新不會再次發送相同的客戶通知。

比較整體營運成本，不要假設計價模式

將 API 費用與郵資及承運商帳戶費用分開。運輸及追蹤服務可能使用不同的計費單位，而綜合平台可能以不同方式打包各項能力。針對你計劃執行的確切工作流程取得報價，或查看適用方案。

詢問可計費使用量如何定義、不成功的請求是否計費、重複提交追蹤資料如何處理，以及使用量超出配額時會發生甚麼事。將工程維護、支援工作，以及維持兩個整合方案一致所需的成本納入考慮。在沒有明確的貨件組合及目前商業條款下，宣稱某一類別較便宜會造成誤導。

檢視安全性及資料保留

運輸整合方案可能處理收件人地址及海關資料。追蹤整合方案也可能處理貨件識別碼及相關客戶資料。確認所需欄位，將憑證限制在必要存取權限內，並避免將密鑰放入瀏覽器端程式碼。

根據你的業務要求檢視資料保留、刪除及存取控制。方便的整合方案不應要求傳送工作流程不需要的客戶資料。

承諾使用前的實際驗證計劃

使用具代表性的貨件進行概念驗證，不要只測試快速入門指南中的成功範例。與營運、工程及客戶支援團隊共同確定驗收標準。

  • 發貨：產生所需的標籤格式，並確認倉庫設備可以使用這些標籤。
  • 訂單映射：測試拆分貨件、多個包裹及替換貨件，同時保留原始歷史記錄。
  • 追蹤：檢查對你的業務重要的承運商及路線的實際事件順序。
  • 異常：確認可採取行動的派送問題能傳達給正確團隊，而不會自動將每次異常掃描都視為失敗。
  • 恢復：中斷請求或 Webhook 端點，並展示應用程式如何對賬缺失資料。
  • 通訊：確認每項客戶通知只由指定系統發送。
  • 商業適配度：使用預期用量及供應商已確認的計費定義估算費用。

決策規則：先購買缺失的能力。如果發貨已經運作，便在不重建履行流程的情況下評估追蹤整合。如果缺少標籤建立功能，先解決運輸執行問題。如果你的應用程式負責完整貨件生命週期，便驗證兩種能力，並選擇較容易由團隊營運的綜合或分開架構。

常見問題

shipping API 是否一定包括追蹤功能？

不一定。有些服務包括兩種能力，而其他服務則透過獨立端點、產品或方案提供。即使包括追蹤功能，也應在將其視為購買後追蹤方案前，確認其事件詳情、更新傳送方式、承運商支援及使用條款。

我可以追蹤由履行合作夥伴建立標籤的包裹嗎？

有可能。你的應用程式需要追蹤整合方案所要求的識別資料，通常包括追蹤號碼，並在必要時包括承運商識別碼或其他驗證資料。確認支援合作夥伴使用的承運商，並確保追蹤號碼可靠地傳入你的系統。

tracking API 會令承運商更快進行掃描嗎？

它無法產生實體承運商掃描，但可以協助你的應用程式取得、整理及分發其追蹤來源提供的資訊。應使用實際貨件評估更新行為，而不是假設 API 能保證即時看見每次運送動態。

要使用兩種能力，我是否需要兩個 API 供應商？

不需要。你需要的是兩項功能，而不一定是兩個供應商。當一個供應商符合你的運輸及追蹤要求時，便使用一個供應商。當分開使用可以保留有效工作流程，或滿足綜合選項無法滿足的特定要求時，才將兩者分開。

tracking API 可以取代訂單管理系統嗎？

不可以。追蹤資料是訂單管理的輸入，而不是庫存分配、履行決策、付款處理或訂單記錄的替代品。你的應用程式仍然需要將每個貨件與正確訂單關聯，並決定貨件事件如何影響業務工作流程。

來源

Loading