首頁博客指南如何為巴西跨境電子商務選擇貨件追蹤 API

如何為巴西跨境電子商務選擇貨件追蹤 API

17TRACK

透過測試您在巴西的實際運輸路線、國際至本地的交接、海關相關事件及派送例外情況，選擇跨境電商的貨件追蹤 API，而不是比較表面的承運商數量。合適的 API 應保留實用的貨件詳情，可靠地與您的系統整合，並支援準確的葡萄牙文客戶訊息，同時避免將不完整的追蹤數據變成派送承諾。

如何選擇跨境貨件追蹤 API

對電商營運主管及工程團隊而言，採購決策最終取決於營運需求：這項整合能否說明訂單目前的位置、識別下一步應由誰處理，並避免客戶支援團隊使用過時或誤導性的資訊？使用以下框架，將這些要求轉化為實際的候選清單及概念驗證。

從您的巴西運輸路線開始，而不是從供應商的承運商目錄開始

承運商清單只是起點，不能證明 API 能追蹤您向該承運商購買的每項服務。跨境貨件可能涉及始發地承運商、國際物流合作夥伴及本地派送營運商。追蹤連續性取決於該特定鏈路上有哪些事件及識別碼可用。

在聯絡供應商前，使用近期貨件建立路線清單。記錄始發國家、運輸服務、國際物流供應商、已知的巴西派送營運商，以及每個階段可用的追蹤號碼。除了主要路線，也要包括經常產生支援工單的低貨量路線。

  • 分開郵政及特快路線。不要假設其中一種路線的成功代表另一種路線已準備就緒。
  • 記錄識別碼變更。確認貨件是否一直使用同一個追蹤號碼，或在交接後獲發另一個號碼。
  • 包括困難目的地及結果。測試延誤貨件、派送失敗嘗試、退件及不完整的追蹤記錄，而不只是成功派送。
  • 識別業務負責人。營運團隊應驗證事件是否有用，工程團隊應驗證整合行為，而支援團隊應驗證客戶解釋是否清晰。

您的首項選擇規則應該很簡單：供應商必須在您的重要路線上展示有用的追蹤能力。其他地區的廣泛覆蓋，無法彌補客戶所使用路線上缺失的交接資訊。

定義可用的追蹤事件必須包含甚麼

「運輸途中」等標準化狀態有助於報告，但對跨境支援而言通常遠遠不夠。要求查看樣本回應，並檢查 API 如何呈現底層事件。您需要區分真正的新動向、翻譯後的描述、重複事件及延遲到達的更新。

要評估的資訊重要原因測試內容
原始事件描述保留廣泛狀態可能省略的詳情。支援團隊能否在標準化狀態旁邊取得承運商的原文？
事件時間及時區處理有助避免錯誤時間線及誤導性的延誤計算。缺少時區偏移、延遲事件及來自不同國家的事件會如何呈現？
承運商及追蹤識別碼將國際運輸與本地派送連結起來。能否連結相關號碼而不建立重複的客戶貨件？
位置資訊在來源提供資料時，提供相關背景。整合能否區分已報告的位置、缺失資訊及推斷資訊？
例外詳情支援採取正確的營運應對措施。您的應用程式能否區分派送嘗試與海關相關問題？

不要要求每個事件都包含所有欄位。上游來源可能會省略資訊。相反，應要求清楚區分已報告的事實、供應商的解讀及不可用的數據。

將海關可見性視為資訊，而非清關權限

對於運往巴西的貨件，海關相關追蹤值得進行專門的驗收測試。一般性的例外狀態可能令支援團隊無法判斷貨件是否正在處理、資料是否缺失，或是否已報告收件人需要採取行動。

評估 API 實際從承運商或物流合作夥伴接收到甚麼資料。不要假設追蹤整合能計算進口費用、提交清關文件、確認付款或放行包裹。這些屬於不同的能力及責任，需要分開驗證。

  • 檢查海關相關事件是否保留原始描述。
  • 確認「需要採取行動」是明確報告的，還是從廣泛狀態推斷出來的。
  • 識別應由哪個官方承運商或物流渠道確認下一步。
  • 防止自動訊息自行編造付款金額、期限或所需文件。

對於由 Correios 處理的貨件，請以其官方網站作為查核面向收件人程序的起點。對於其他派送安排，請向已簽約的物流供應商確認適當的官方渠道。追蹤通知應解釋已報告的情況並安全地指引客戶，而不是將未經核實的指示呈現為官方要求。

超越順利情況，測試整合可靠性

API 請求成功並不能證明貨件在整個運送過程中都會保持同步。要求供應商說明註冊、更新取得、事件傳送、追蹤到期及中斷後恢復的方式。在承諾採用前，根據文件核實答案並測試實際行為。

Webhook 傳送及恢復

如果供應商提供 Webhook，請確認驗證、重試行為、逾時預期，以及任何重播或恢復機制。除非供應商明確保證，否則應設計接收器以處理重複傳送及順序錯亂的事件。及時確認收到事件、將處理工作加入佇列，並避免直接根據未經驗證的傳入 payload 發送客戶訊息。

詢問您的端點不可用時會發生甚麼。您的團隊需要一套有文件記錄的方法來核對遺漏的更新，無論是透過取得端點、重播程序，還是其他受支援的恢復方式。確認所選方法符合預期的中斷情況。

承運商識別及貨件註冊

測試有歧義的追蹤號碼，而不要假設自動偵測總能識別預期的承運商。在支援的情況下，提供已知的承運商識別碼可能減少歧義。也要測試重複註冊、無效號碼、首次掃描延遲，以及貨件獲得第二個識別碼的情況。

新鮮度及可觀察性

區分承運商事件發生的時間與您的系統接收事件的時間。根據有文件記錄的參考值衡量兩者差距，同時注意承運商的公開追蹤頁面本身可能更新延遲，或與另一個數據渠道有所不同。詢問供應商如何處理追蹤停滯及來源暫時故障；不要將每段沒有更新的期間都解讀為包裹遺失。

圍繞下一項有用行動建立葡萄牙文訊息

葡萄牙文在地化不只是翻譯狀態名稱。客戶需要知道發生了甚麼、是否需要採取行動，以及在哪裏取得可靠協助。支援人員也可能需要承運商的原始描述，以調查異常事件。

將三個層次分開：來源事件、您的內部營運分類，以及面向客戶的訊息。例如，不明確的海關事件不應自動變成付款要求。到達掃描也不應變成「派送中」通知。

為重複事件、較舊事件及低價值中間掃描建立通知抑制規則。如果您顯示派送預計時間，請核實其來源及含義。商戶承諾、承運商預計時間及供應商生成的預測是不同的內容，不應互換呈現。

一併檢查私隱、安全及商業條款

在評估合約條款前，先列出您的整合將傳送的資料。追蹤記錄可以與客戶訂單連結，因此應減少不必要的個人資料，並限制貨件數據的存取權限。不要僅因 payload 允許額外欄位，就傳送客戶稅務識別碼、地址或電話號碼。

對於涉及巴西的個人資料處理，請讓私隱或法律團隊參與評估 LGPD 下的責任。巴西數據保護機構 ANPD是官方參考點。根據您的安排，檢視處理角色、保留、刪除、分包處理商、國際傳輸及事故程序。供應商的一般安全聲明不能取代這項評估。

要求供應商根據您自己的貨件數量及生命周期提供書面商業情境。確認哪些項目會收費：註冊、已追蹤貨件、API 請求、更新，還是其他單位。詢問重複貨件、長期運送貨件、重新追蹤、超額用量、支援及歷史存取如何影響報價。這些都需要核實，不應假設任何供應商的定價方式。

比較總營運成本，包括工程維護及人工處理例外情況的成本。如果整合令您最繁忙的路線仍依賴人工檢查，較低的單位報價不一定代表較低成本的方案。

17TRACK 在評估中的定位

對於評估追蹤整合的團隊，值得檢視的 17TRACK 產品是其Tracking API。使用官方 API 文件評估建議的實施方案，並要求確認您指定的巴西承運商、服務及交接情境。

套用本文所述的相同驗收測試。不要將消費者追蹤結果視為 API 傳送行為、合約可用性或特定資料欄位的證明。直接確認 API 回應、整合要求、商業條款及支援安排。

當您的路線涉及多個物流供應商，而團隊希望使用共同介面時，多承運商整合值得評估。當某項已簽約服務佔主導地位並符合您的數據要求時，直接整合承運商可能已經足夠。無論採用哪種架構，都不能免除測試實際貨件歷史的需要。

使用明確的採購門檻進行概念驗證

使用歷史貨件檢查已完成的運送過程，並使用現行貨件測試更新傳送。單靠歷史追蹤無法證明新事件會多快傳送到您的系統。在需要時取得許可，並避免分享不必要的客戶資料。

  1. 選擇具代表性的樣本。涵蓋重要始發地、服務、本地派送安排及例外類型。
  2. 為每件貨件定義參考資料。記錄相關承運商歷史及任何已知識別碼變更。記錄分歧，而不是默默選擇較有利的結果。
  3. 衡量路線層面的結果。評估註冊成功率、相關事件可用性、交接連續性及觀察到的更新延遲。清楚保留分母及缺失案例。
  4. 執行故障處理測試。中斷 Webhook 接收器、提交重複資料，並測試恢復而不產生重複客戶通知。
  5. 與支援團隊檢視訊息。詢問支援人員輸出是否解釋了貨件情況，並指出有理據支持的下一步行動。
  6. 批准責任歸屬及成本。為整合故障、承運商升級處理、客戶訊息及發票審核分配責任。

在檢視結果前，根據您的業務需要設定驗收門檻，而不是採用任意的通用基準。將必要路線覆蓋、安全整合及錯過更新後的恢復能力視為採購門檻。只有在達到這些門檻後，才使用次要功能區分供應商。

選擇能在實際操作中令您重要的巴西貨件旅程變得易於理解及恢復的 API。如果關鍵交接或例外情況仍未經核實，請在擴大部署前透過額外測試或書面實施承諾解決。

常見問題

支援 Correios 是否足以處理進入巴西的貨件？

不一定。這取決於您簽約的路線及最終派送安排。應一併測試國際段、任何識別碼變更及本地段。列出某一營運商並不能證明整個旅程都具備可見性。

追蹤 API 能否解決海關延誤？

追蹤可以協助顯示已報告的事件，並將問題轉交給適當的人員。但追蹤本身並不代表有權提交文件、收取進口付款或放行貨物。如果您的工作流程需要這些功能，請另行核實。

我們應使用 Webhook 還是輪詢？

在支援的情況下，Webhook 可以減少重複請求的需要，但仍需要驗證、重複處理及恢復規劃。根據供應商支援的設計及限制，輪詢可以作為主要取得方法或核對機制。

追蹤停止更新時應怎樣處理？

將整合問題與沒有新報告動向的貨件區分開來。檢查資料接收健康狀況及官方來源，然後套用針對路線的升級政策。不要自動將貨件標記為遺失，或承諾新的派送日期。

追蹤 API 會取代我們的訂單管理系統嗎？

不會。應將追蹤視為貨件資訊輸入。您的訂單管理及支援工作流程仍應負責訂單身份、客戶溝通規則、退款、補發及升級決策。

來源