跳轉到主要內容
此頁面由 AI 自動翻譯。如有任何疑問或不一致之處,請以英文版本為準。

概覽

當 Return Helper 系統中發生事件時(例如標籤生成或退件運貨單(Return Shipment)抵達倉庫),Webhooks 會傳遞非同步通知。您的伺服器必須公開一個 HTTPS 端點以接收這些 POST 請求。
欄位可能隨時新增。 Return Helper 會在不事先通知的情況下於 Webhook 負載中新增欄位。請勿對負載結構進行嚴格驗證——請忽略無法識別的欄位,並照常回傳 2xx。

設定您的 Webhook 端點

端點要求

在註冊端點之前,請確保您的端點符合以下要求:
  • 可公開存取 — URL 必須可從網際網路存取(不可使用 VPN、localhost 或僅限內部存取的位址)
  • HTTPS — 端點必須使用具有有效 TLS 憑證的 HTTPS
  • HTTP POST — 端點必須接受含 application/json 主體的 POST 請求
  • 回應 2xx — 您的伺服器在收到請求後必須迅速回傳 2xx 狀態;任何其他狀態碼或逾時均視為傳遞失敗
  • 快速回應 — 如有需要請以非同步方式處理事件;請勿在回應前執行繁重的作業,以避免傳遞逾時
  • 接受您未處理的事件 — 對於您的處理程式未處理的任何 category / action,也請回傳 2xx。新事件會陸續加入,並傳送至每個已註冊的端點。

註冊您的端點

請透過 API 自行註冊及管理您的 Webhook 端點: 請先部署您的處理器,再進行註冊。Return Helper 會向該 URL 發送一次已簽章的驗證請求,只有在 30 秒內回傳 2xx 狀態時,端點才會被儲存。 每個已註冊的端點都會收到您帳戶的所有事件。請在您這一端依 category 與 action 欄位進行篩選。 沙箱環境與正式環境需分別註冊。請在每個需要接收通知的環境中,使用該環境的憑證呼叫 API。

事件傳遞

時間 — 事件可能在觸發動作後幾秒鐘抵達,在極少數情況下可能延遲至幾分鐘後。 重複事件 — 您的端點可能收到相同事件超過一次。請追蹤已處理的 notificationId 進行去重;notificationId 在每次推送中均為唯一且必定存在,因此可單獨作為穩定的等冪鍵使用。 事件順序 — 不保證傳遞順序。請將您的處理器設計為可以任意順序處理事件。例如,inventoryCreated 可能在 warehouseMarkShipmentArrivedV2 之前抵達。請使用 API 取得您收到的亂序事件中所參考的任何物件。 每個事件均包含 ISO 8601 格式的 eventTime 欄位。

通知標頭

每個 Webhook 請求均包含以下標頭:

舊版標頭

以下標頭仍會隨每則通知送出,且不會被移除。新的整合請改為讀取上方的標頭。
HTTP 標頭名稱不區分大小寫,部分框架會將其正規化。上表為 Return Helper 實際送出的大小寫形式;若您的框架會將傳入的標頭名稱轉為小寫,請以不區分大小寫的方式比對。

簽章驗證

在處理任何 Payload 之前,請務必先驗證簽章。請使用原始請求主體 — 任何轉換(例如框架重新序列化 JSON)都會導致驗證失敗。
您的簽署金鑰由 Return Helper 提供(已進行 Base64 編碼)。請妥善保管並切勿暴露。您可以在使用者入口網站中與 API Key 和 Token 相同的畫面找到它——請參閱 認證 一節中的截圖;也可以使用取得 Signing Key以程式方式讀取。

操作範例

以下為收到的請求範例: 標頭:
主體(原始 JSON,不得重新序列化):

逐步驗證說明

步驟 1 — 從 ReturnHelper-Signature 標頭中提取簽章(用於最後比對):
步驟 2 — 從 RETURNHELPER-TRIGGERED-AT 標頭中提取時間戳記:
步驟 3 — 建立 string_to_sign 依序串接以下四個值(無分隔符):
  1. HTTP 方法:POST
  2. 您的通知端點 URL:https://s2024-01-12.free.beeceptor.com
  3. 步驟 2 取得的 RETURNHELPER-TRIGGERED-AT 值
  4. 原始 JSON 主體
串接後的字串:
接著對整個串接字串進行 Base64 編碼。結果即為 string_to_sign:
步驟 4 — 計算 HMAC-SHA256 簽章 使用範例簽署金鑰(您的實際金鑰將有所不同):
操作步驟:
  1. 將 string_to_sign(步驟 3)從 Base64 解碼 → 位元組陣列
  2. 將您的簽署金鑰從 Base64 解碼 → 位元組陣列
  3. 使用簽署金鑰位元組對 string_to_sign 位元組計算 HMAC-SHA256 → 簽章位元組陣列
  4. 將簽章位元組陣列進行 Base64 編碼
預期結果:
步驟 5 — 比對簽章 將步驟 4 計算出的簽章與步驟 1 提取的簽章進行比對。請使用常數時間字串比對以防止時序攻擊。 額外安全措施: 拒絕 eventTime 與您系統時鐘相差超過 15 分鐘的事件(重放攻擊防護)。

範例程式碼

重試機制

請以 2xx HTTP 狀態碼回應以確認已收到。非 2xx 回應將觸發重試。連續 10 次失敗後,傳遞至您端點的通知將暫停 24 小時。

通知主體公共欄位

所有通知主體共享以下頂層欄位:

通知事件參考


通知 Payload

標籤結果

當退貨標籤請求完成時發送(成功或失敗)。
請務必使用 shipmentId 將標籤與您系統中的退件運貨單(Return Shipment)進行匹配 — 請勿使用 labelId。在極少數情況下,承運商故障會導致為同一 shipmentId 發出新標籤(具有新的 labelId)。
category: labelGenerated / action: labelGenerated label 中的關鍵欄位:

區域標籤 URL

regions 提供與 labelUrl 同一標籤檔案的其他 URL。在對應區域下載或列印標籤時使用。
  • 每個值都指向與 labelUrl 相同的 PDF,僅主機不同。
  • 所有帳戶皆包含此欄位,無需任何設定。
  • 僅 labelGenerated 事件包含此欄位。API 回應及其他 Webhook 事件中的標籤 URL 僅使用 labelUrl 的主機。如需區域 URL,請從此事件中儲存。
  • 當 labelUrl 為 null(標籤請求失敗)時,regions 為 {}。
  • 請忽略無法識別的鍵。若所需的鍵不存在,請使用 labelUrl。
成功範例:
失敗範例:

倉庫退件運貨單(Return Shipment)抵達(v2)

當倉庫標記退件運貨單(Return Shipment)已收到時發送。此後必定跟隨一個或多個庫存已建立事件。
此事件會回傳您的 sellerReferenceNumber,是您的訂單紀錄與 Return Helper 識別碼之間的主要對帳點。預設的 V202207 會在一份打包負載中攜帶三個層級的 SRN;V202407 僅攜帶 Shipment 層級的 SRN。完整的對帳工作流與版本差異見 Seller Reference Number。
category: rsl / action: markShipmentArrive / version: 202407 shipment 中的關鍵欄位:

庫存已建立

在退件運貨單(Return Shipment)收到後(或 VAS 拆分後)發送,通知已建立新的退貨庫存(Return Inventory)記錄。每筆庫存品項發送一個事件 — 若在同一標籤下收到多個包裹,同一退件運貨單(Return Shipment)可能產生多個事件。
此負載中沒有 sellerReferenceNumber。 returnInventory 與 shipment 都不攜帶 sellerReferenceNumber;只有 shipment.referenceNumber 存在,而該欄位回傳的是您傳入的 orderNumber——並非賣家參考號。如果您依賴 sellerReferenceNumber 將庫存與您自己的紀錄對帳,請不要只訂閱 newInventoryCreated。請同時訂閱 Warehouse Shipment Arrived(V202207 下在三個層級都攜帶 SRN)或 Inventory Handling Complete(在 returnInventory.sellerReferenceNumber 上攜帶 Line Item 層級的 SRN)。完整的對帳策略見 Seller Reference Number。
category: newInventoryCreated / action: newInventoryCreated returnInventory 中的關鍵欄位:

圖片已更新

當退貨庫存(Return Inventory)明細品項的圖片被新增、變更或移除時發送。 category: rrli / action: changeLineItemImage 頂層 Payload 欄位: returnRequestLineItem 中的關鍵欄位:
imageUrlList 中的 URL 可公開存取、不會過期,可在用戶端安全快取。請直接保存使用。空狀態:imageUrlList: []。

未知來件(Unknown Shipment)已指派

當沒有先前退貨申請(Return Request)的退件運貨單(Return Shipment)被識別並指派給賣家時發送。 category: rsl / action: assignUnknown / version: 202407 returnInventory 中的關鍵欄位: unknownShipment 中的關鍵欄位:

回收狀態更新

Recall 即將停用。要把庫存寄至 Return Helper 香港倉庫,請建立 destinationType: RH_WAREHOUSE 的 Consolidate Shipping Order。
當回收追蹤號碼更新或取件狀態變更時發送。 category: recall / action: recallUpdateStatus recallUpdateTypeStatus 值:

重寄狀態更新

當重寄追蹤號碼更新,或重寄完成或失敗時發送。 category: resend / action: updateResendStatus 頂層 Payload 欄位: resend 中的關鍵欄位: 每筆 resendShipmentList 項目中的關鍵欄位:
resendShipmentList 總是只有一筆項目——一筆重寄有且僅有一張重寄運貨單。請直接讀取 resendShipmentList[0]。
trackingNumber 不是 頂層欄位,它位於重寄運貨單內:resendShipmentList[0].trackingNumber。
檢查 resend.resendStatusCode:
  • 3 — 已完成(讀取 resendShipmentList[0].trackingNumber)
  • 4 — 失敗(讀取 resendShipmentList[0].error)
使用 resendShipmentList[0].sellerReferenceNumber 將事件對應到您自己的訂單紀錄,就不必儲存 Return Helper 的 resendId。
只有當補寄是由 Enterprise 帳戶透過 以 SKU 建立 Resend 建立、且有提供參考編號時,sellerReferenceNumber 才會有值;其餘補寄一律為 null。若要以該值即時查詢補寄,請使用 以 Seller Reference Number 搜尋 Resend。

VAS 更新

當增值服務(VAS)完成時發送。 category: rrliv / action: vasUpdated updateVasList 中的每個品項:
imageUrlList 中的 URL 可公開存取、不會過期,可在用戶端安全快取。請直接保存使用。空狀態:imageUrlList: [](某些 VAS 類型不產生圖片;這些項目仍出現在 updateVasList[] 中,但 imageUrlList 為空陣列)。

庫存處理完成

當倉庫完成處理指示(丟棄、重寄、回收等)時發送。 category: rinv / action: completeInventoryHandling returnInventory 中的關鍵欄位: handlingCode 值: handlingStatusCode 值:

庫存重新校準

當倉庫更新退貨庫存(Return Inventory)的測量尺寸或重量時發送。 category: completeRecalibrate / action: completeRecalibrate recalibrateSupplement 中的關鍵欄位:

庫存中繼資料已更新

當倉庫或使用者新增或更新退貨庫存(Return Inventory)的中繼資料時發送。 category: updateReturnInventoryMeta / action: updateReturnInventoryMeta Payload 包含與庫存已建立相同結構的 returnInventory,其中包含更新後的 returnInventoryMetaList。 metaType 值:
  • usr — 使用者提供的中繼資料
  • whs — 倉庫提供的中繼資料

RMA 已更新

當倉庫更正不正確的 RMA 指派時發送。 category: notifyUserRmaSwapped / action: notifyUserRmaSwapped payload 中的關鍵欄位:

SKU 已更新

當賣家更新退貨庫存(Return Inventory)的 SKU 時發送。 category: userUpdateReturnInventorySku / action: userUpdateReturnInventorySku Payload 包含 returnRequest 和 returnInventory。 returnRequest 中的關鍵欄位: returnInventory 物件遵循與庫存處理完成相同的結構,包含更新後的 sku 欄位。

明細品項拆分

當 VAS 操作將包裹拆分為多個庫存時發送。包含每個產生的包裹的新明細品項和庫存記錄。 category: lineItemVasReturnInventoryLineItem / action: splitLineItem 頂層 Payload 欄位: splitLineItemAndReturnInventoryList 中的每個品項包含:

倉庫備註已更新

當倉庫更新退貨申請(Return Request)的備註時發送。 category: warehouseUpdateWarehouseRemarks / action: warehouseUpdateWarehouseRemarks Payload 包含三個物件:
  • returnRequest — 退貨申請(Return Request)(與 SKU 已更新 → returnRequest 結構相同)
  • shipment — 包含完整地址詳情、尺寸、重量、費用及 customFieldMap 的退件運貨單(Return Shipment)記錄
  • returnInventory — 受影響的庫存(與庫存處理完成結構相同),包含更新後的 warehouseRemarks 欄位

買家退貨標籤已生成

當買家在品牌退貨入口網站建立退貨且標籤已生成時發送。
僅適用於整合了 Return Helper 品牌退貨服務的客戶。
category: buyerReturnRrLabel / action: buyerReturnLabelGenerated 請檢查 buyerReturn.labelRequestStatusCode 是否為 "success" 或 "fail"。 buyerReturn 中的關鍵欄位: buyerReturnLineItemList 中的每個品項:

Shopify 買家退貨已建立

當買家透過 Shopify 整合建立退貨申請(Return Request)時發送。 category: shopifyBuyerCreateReturn / action: shopifyBuyerCreateReturn shopifyReturn 中的關鍵欄位: shopifyReturnLineItemList 中的每個品項:

合併退件運貨單(Return Shipment)費用已更新

當合併退件運貨單(Return Shipment)訂單的運送費用更新時發送。 category: consolidateShippingOrderShippingFeeUpdated / action: consolidateShippingOrderShippingFeeUpdated order 中的關鍵欄位:

合併退件運貨單(Return Shipment)全部已打包

當倉庫已將合併訂單的所有庫存打包入箱時發送。 category: consolidateShippingOrderInventoryAllPacked / action: consolidateShippingOrderInventoryAllPacked order 中的關鍵欄位: shipmentList 中的每個品項: boxList 中的每個品項: consolidateShippingInventoryList 中的每個品項:
一個箱子可裝 RMA 明細、FNSKU 明細或兩者。不含 RMA 明細的箱子同樣會列出。

合併退件運貨單(Return Shipment)已寄出

當倉庫將合併退件運貨單(Return Shipment)派送至承運商時發送。 category: consolidateShippingShipmentSent / action: consolidateShippingShipmentSent shipment 中的關鍵欄位:

合併退件運貨單(Return Shipment) AWB 已更新

當合併退件運貨單(Return Shipment)的航空退件運貨單(Return Shipment)號碼更新時發送。 category: consolidateShippingShipmentShipped / action: consolidateShippingShipmentShipped shipment 物件遵循與合併退件運貨單(Return Shipment)已寄出相同的結構,包含更新後的 awb 欄位。 對於 RH_WAREHOUSE 訂單,倉庫記錄 AWB 時會發送此事件。consolidateShippingShipmentStatus 為 IN_TRANSIT,此時尚未收費:Shipment 到達時才收費,並透過 合併退件運貨單(Return Shipment)已到達 通知。

合併退件運貨單(Return Shipment)已到達

RH_WAREHOUSE 訂單的每個 Shipment 到達 Return Helper 倉庫並收取運費時,各發送一次。 category: consolidateShippingShipmentArrived / action: consolidateShippingShipmentArrived / version: 202609
版本 202609 需要申請開通。請聯絡 Return Helper 客服。
含明細的 Shipment 有 3 個的訂單會發送 3 次事件:1/3、2/3、3/3。 order 中的欄位: 版本 202609 不包含 shippingMethod。 shipmentList 中的每個品項: consolidateShippingInventoryList 中的每個品項:

合併訂單已完成

合併訂單的所有明細都已寄出時發送。對於 RH_WAREHOUSE 訂單,所有含明細的 Shipment 也必須已到達;此事件在訂單最後一個 合併退件運貨單(Return Shipment)已到達 之後發送。 category: consolidateShippingOrderCompleted / action: consolidateShippingOrderCompleted order 物件遵循與合併退件運貨單(Return Shipment)全部已打包相同的結構,包含完整的 shipmentList(含 boxList 及庫存詳情)。

合併訂單已取消

當倉庫強制取消合併退件運貨單(Return Shipment)訂單時發送。 category: consolidateShippingOrderCancelled / action: consolidateShippingOrderCancelled order 中的關鍵欄位:

交易已新增

每當有交易記入您的帳戶時發送一次,包括扣款、退款、重新扣款及儲值。
apiTransaction.notes 通常會說明該交易對應的操作,因此您無須解析 headId 即可了解交易內容。
category: transaction / action: addTransaction / version: 202610 apiTransaction 中的關鍵欄位: apiBalance 中的關鍵欄位:
balance 是該交易記入當下的值,而非您目前的餘額。事件可能不依順序送達。如需目前餘額,請呼叫取得 API 帳戶餘額。

headId 對應的紀錄

在下表中找到 transactionType,再將 headId 與您已從所列事件或回應中取得的 ID 進行比對。headId 一律為字串。退款或重新扣款的 headId 與其所調整的扣款相同。 ¹ rsl 為生成失敗的標籤退款。headId 為 labelId;若失敗的標籤是買家退貨標籤,則為 returnRequestId。
  • 所有交易都會發送;您無法只訂閱個別類型。請依 transactionType 及 amount 的正負進行分支處理。
  • 可能會新增 transactionType 值。遇到無法識別的類型時,仍請記錄 amount 及 balance;請勿拒收該事件。
  • 一個退件運貨單(Return Shipment)可能有多張標籤,因此可能有多筆 csl。請使用標籤結果將 labelId 對應至 shipmentId。
  • createOn 是交易記入的時間;eventTime 是通知發送的時間。