概要
Webhookは、Return Helperシステムでイベントが発生した際に非同期通知を配信します — たとえば、ラベルが生成されたときや、配送が倉庫に到着したときなど。これらのPOSTリクエストを受信するために、サーバーはHTTPSエンドポイントを公開する必要があります。Webhookエンドポイントの設定
エンドポイントの要件
セットアップリクエストを送信する前に、エンドポイントが以下の要件を満たしていることを確認してください:- 公開アクセス可能 — URLはインターネットから到達可能でなければなりません(VPN、localhost、または内部専用アドレスは不可)
- HTTPS — エンドポイントは有効なTLS証明書を持つHTTPSで提供される必要があります
- HTTP POST — エンドポイントは
application/jsonボディを持つPOSTリクエストを受け入れる必要があります - HTTP 200を返す — サーバーはリクエストを受信した直後に
200 OKステータスを返す必要があります;その他のステータスコードやタイムアウトは配信失敗として処理されます - 高速レスポンス — 必要に応じてイベントを非同期で処理します;配信タイムアウトを避けるため、レスポンス前に重い処理を行わないでください
エンドポイントの登録
Webhookエンドポイントを登録するには、Webhookセットアップリクエストフォームにご記入ください。フォームにはセットアップを迅速に完了するために必要なすべての情報が含まれており、エンドポイントを有効にする最も速い方法です。上記のフォームを使用することをお勧めします。これにより、必要なすべての詳細が一度に取得されます。フォームを使用できない場合は、メールでリクエストを送信することもできます — 以下のテンプレートを参照してください。
メールテンプレート(フォームを使用できない場合)
メールテンプレート(フォームを使用できない場合)
メールで連絡する場合は、support@returnhelper.comに以下を送信してください:
イベント配信
タイミング — イベントはトリガーアクションの数秒後に届く場合があり、まれに数分後になることがあります。 重複イベント — エンドポイントが同じイベントを複数回受信する場合があります。処理済みのnotificationId を追跡して重複を排除してください。notificationId はイベントごとに一意で、すべてのウェブフック通知に含まれるため、それ単体で安定した冪等キーとして使用できます。
イベントの順序 — 配信順序は保証されていません。任意の順序でイベントを処理できるようにハンドラーを設計してください。たとえば、inventoryCreatedがwarehouseMarkShipmentArrivedV2より前に届く場合があります。順序外で受信したイベントで参照されているオブジェクトを取得するには、APIを使用してください。
各イベントにはISO 8601形式のeventTimeフィールドが含まれています。
通知ヘッダー
すべてのWebhookリクエストには以下のヘッダーが含まれています:旧ヘッダー
以下のヘッダーは引き続きすべての通知で送信され、削除される予定はありません。新規の連携では上表のヘッダーを読み取ってください。HTTP ヘッダー名は大文字・小文字を区別せず、フレームワークによっては正規化されます。上表は Return Helper が実際に送信する表記です。受信ヘッダー名が小文字化されるフレームワークをお使いの場合は、大文字・小文字を区別せずに照合してください。
署名の検証
署名キーはReturn Helperから提供されます(Base64エンコードされています)。安全に保管し、公開しないでください。API キーおよびトークンと同じ画面(ユーザーポータル)で確認できます——認証 のスクリーンショットを参照してください。また、Signing Key を取得でプログラムから読み取ることもできます。詳細な例
以下の受信リクエストがあるとします: ヘッダー:ステップバイステップの検証
ステップ1 —ReturnHelper-Signature ヘッダーから署名を抽出する(最後の比較用):
RETURNHELPER-TRIGGERED-AT ヘッダーからタイムスタンプを抽出する:
string_to_signを構築する
以下の4つの値を順番に連結します(区切り文字なし):
- HTTPメソッド:
POST - 通知エンドポイントURL:
https://s2024-01-12.free.beeceptor.com - ステップ2で取得した
RETURNHELPER-TRIGGERED-ATの値 - 生のJSONボディ
string_to_signです:
string_to_sign(ステップ3)をBase64からバイト配列にデコードする- 署名キーをBase64からバイト配列にデコードする
- 署名キーバイトを使用して
string_to_signバイトに対してHMAC-SHA256を計算する → 署名バイト配列 - 署名バイト配列をBase64エンコードする
eventTimeがシステムクロックと15分以上異なるイベントを拒否してください(リプレイ攻撃保護)。
サンプルコード
再試行メカニズム
受信を確認するために2xx HTTPステータスコードで応答してください。2xx以外のレスポンスは再試行をトリガーします。10回連続して失敗した後、エンドポイントへの通知配信は24時間停止されます。
共通ボディフィールド
すべての通知ボディはこれらのトップレベルフィールドを共有しています:通知イベントリファレンス
通知ペイロード
ラベル結果
返品ラベルリクエストが完了したとき(成功または失敗)に送信されます。category: labelGenerated / action: labelGenerated
labelの主要フィールド:
成功例:
倉庫配送到着(v2)
倉庫が配送を受領済みとしてマークしたときに送信されます。常に1つ以上の在庫作成済みイベントが続きます。このイベントは
sellerReferenceNumber を返却し、お客様の注文レコードと Return Helper の識別子との主要な突合ポイントとなります。デフォルトの V202207 は 3 つのレイヤーすべての SRN を 1 つのバンドルペイロードで運びます。V202407 は Shipment レイヤーの SRN のみを運びます。完全な突合ワークフローとバージョンの差異については Seller Reference Number を参照してください。category: rsl / action: markShipmentArrive / version: 202407
shipmentの主要フィールド:
在庫作成済み
配送が受領された後(またはVAS分割が発生した後)、新しい返品在庫(Return Inventory)レコードが作成されたことを通知するために送信されます。在庫アイテムごとに1つのイベントが送信されます — 同じラベルの下で複数の荷物が受領された場合、1つの配送で複数のイベントが生成される場合があります。このペイロードには
sellerReferenceNumber が含まれません。 returnInventory と shipment のいずれも sellerReferenceNumber を運びません。存在するのは shipment.referenceNumber のみで、このフィールドはお客様が指定した orderNumber を返却するだけで、SRN ではありません。sellerReferenceNumber に基づいて在庫を自社レコードと突合する場合、newInventoryCreated 単独の購読は避けてください。Warehouse Shipment Arrived(V202207 では 3 レイヤーすべての SRN を運びます)または Inventory Handling Complete(returnInventory.sellerReferenceNumber に Line Item レイヤーの SRN を運びます)と組み合わせて使用してください。完全な突合戦略については Seller Reference Number を参照してください。category: newInventoryCreated / action: newInventoryCreated
returnInventoryの主要フィールド:
画像更新済み
返品在庫(Return Inventory)ラインアイテムの画像が追加、変更、または削除されたときに送信されます。category: rrli / action: changeLineItemImage
トップレベルのペイロードフィールド:
returnRequestLineItemの主要フィールド:
imageUrlList の URL は公開アクセス可能、期限切れなし、クライアント側で安全にキャッシュ可能です。そのまま保持して使用してください。空状態:imageUrlList: []。
不明な配送が割り当てられた
返品リクエストのない配送が識別され、販売者に割り当てられたときに送信されます。category: rsl / action: assignUnknown / version: 202407
returnInventoryの主要フィールド:
unknownShipmentの主要フィールド:
リコールステータス更新
リコール追跡番号が更新されるか、集荷ステータスが変更されたときに送信されます。category: recall / action: recallUpdateStatus
recallUpdateTypeStatusの値:
再送ステータス更新
再送追跡番号が更新されるか、再送が完了または失敗したときに送信されます。category: resend / action: updateResendStatus
トップレベルのペイロードフィールド:
resendの主要フィールド:
resendShipmentListの各エントリの主要フィールド:
resendShipmentList には常に 1 件のエントリのみが含まれます——1 つの resend に対して resend shipment は必ず 1 つだけです。resendShipmentList[0] として読み取ってください。resend.resendStatusCodeを確認してください:
3— 完了(resendShipmentList[0].trackingNumberを確認)4— 失敗(resendShipmentList[0].errorを確認)
resendShipmentList[0].sellerReferenceNumber を使うと、Return Helper の resendId を保存しなくてもイベントをお客様自身の注文レコードと突き合わせられます。
sellerReferenceNumber に値が入るのは、Enterprise アカウントが SKU で Resend を作成 で参照番号を指定して作成した resend のみです。それ以外の resend では null になります。この値で resend を随時参照するには、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
ペイロードには、更新されたreturnInventoryMetaListを含む、在庫作成済みと同じ構造のreturnInventoryが含まれています。
metaTypeの値:
usr— ユーザーが提供したメタwhs— 倉庫が提供したメタ
RMA更新済み
倉庫が誤ったRMAの割り当てを修正したときに送信されます。category: notifyUserRmaSwapped / action: notifyUserRmaSwapped
payloadの主要フィールド:
SKU更新済み
販売者が返品在庫(Return Inventory)のSKUを更新したときに送信されます。category: userUpdateReturnInventorySku / action: userUpdateReturnInventorySku
ペイロードにはreturnRequestとreturnInventoryが含まれています。
returnRequestの主要フィールド:
returnInventoryオブジェクトは、更新されたskuフィールドを含む、在庫処理完了と同じ構造に従います。
ラインアイテム分割
VAS操作が荷物を複数の在庫に分割したときに送信されます。各結果の荷物の新しいラインアイテムと在庫レコードが含まれています。category: lineItemVasReturnInventoryLineItem / action: splitLineItem
トップレベルのペイロードフィールド:
splitLineItemAndReturnInventoryListの各アイテムには以下が含まれます:
倉庫備考更新済み
倉庫が返品リクエストの備考を更新したときに送信されます。category: warehouseUpdateWarehouseRemarks / action: warehouseUpdateWarehouseRemarks
ペイロードには3つのオブジェクトが含まれています:
returnRequest— 返品リクエスト(SKU更新済み → returnRequestと同じ構造)shipment— 完全な住所詳細、寸法、重量、コスト、customFieldMapを含む配送レコードreturnInventory— 影響を受けた在庫(在庫処理完了と同じ構造)、更新されたwarehouseRemarksフィールドを含む
購入者返品ラベル生成済み
購入者がブランド返品ポータルで返品を作成し、ラベルが生成されたときに送信されます。Return Helperのブランド返品サービスに連携している顧客にのみ適用されます。
category: buyerReturnRrLabel / action: buyerReturnLabelGenerated
buyerReturn.labelRequestStatusCodeで"success"または"fail"を確認してください。
buyerReturnの主要フィールド:
buyerReturnLineItemListの各アイテム:
Shopify購入者返品作成済み
購入者がShopify連携を通じて返品リクエストを作成したときに送信されます。category: shopifyBuyerCreateReturn / action: shopifyBuyerCreateReturn
shopifyReturnの主要フィールド:
shopifyReturnLineItemListの各アイテム:
統合配送コスト更新済み
統合配送注文の配送コストが更新されたときに送信されます。category: consolidateShippingOrderShippingFeeUpdated / action: consolidateShippingOrderShippingFeeUpdated
orderの主要フィールド:
統合配送すべて梱包済み
倉庫が統合注文のすべての在庫をボックスに梱包したときに送信されます。category: consolidateShippingOrderInventoryAllPacked / action: consolidateShippingOrderInventoryAllPacked
orderの主要フィールド:
shipmentListの各アイテム:
boxListの各アイテム:
consolidateShippingInventoryListの各アイテム:
統合配送発送済み
倉庫が統合配送をキャリアに発送したときに送信されます。category: consolidateShippingShipmentSent / action: consolidateShippingShipmentSent
shipmentの主要フィールド:
統合配送AWB更新済み
統合配送の航空貨物運送状番号が更新されたときに送信されます。category: consolidateShippingShipmentShipped / action: consolidateShippingShipmentShipped
shipmentオブジェクトは、更新されたawbフィールドを含む、統合配送発送済みと同じ構造に従います。
統合注文完了
統合注文のすべての配送が発送されたときに送信されます。category: consolidateShippingOrderCompleted / action: consolidateShippingOrderCompleted
orderオブジェクトは、boxListと在庫詳細を含む完全なshipmentListを含む、統合配送すべて梱包済みと同じ構造に従います。
統合注文キャンセル
倉庫が統合配送注文を強制キャンセルしたときに送信されます。category: consolidateShippingOrderCancelled / action: consolidateShippingOrderCancelled
orderの主要フィールド: