メインコンテンツへスキップ
このページはAIによって自動翻訳されています。不明点や相違がある場合は、英語版を正式版として参照してください。

概要

Webhookは、Return Helperシステムでイベントが発生した際に非同期通知を配信します — たとえば、ラベルが生成されたときや、配送が倉庫に到着したときなど。これらのPOSTリクエストを受信するために、サーバーはHTTPSエンドポイントを公開する必要があります。
フィールドは予告なく追加されます。 Return Helper は、事前の通知なく Webhook ペイロードにフィールドを追加します。ペイロードのスキーマを厳密に検証せず、認識できないフィールドは無視したうえで、通常どおり 2xx を返してください。

Webhookエンドポイントの設定

エンドポイントの要件

エンドポイントを登録する前に、以下の要件を満たしていることを確認してください:
  • 公開アクセス可能 — URLはインターネットから到達可能でなければなりません(VPN、localhost、または内部専用アドレスは不可)
  • HTTPS — エンドポイントは有効なTLS証明書を持つHTTPSで提供される必要があります
  • HTTP POST — エンドポイントはapplication/jsonボディを持つPOSTリクエストを受け入れる必要があります
  • 2xxを返す — サーバーはリクエストを受信した直後に2xxステータスを返す必要があります;その他のステータスコードやタイムアウトは配信失敗として処理されます
  • 高速レスポンス — 必要に応じてイベントを非同期で処理します;配信タイムアウトを避けるため、レスポンス前に重い処理を行わないでください
  • 処理しないイベントも受け入れる — ハンドラーで処理しない category / action に対しても 2xx を返してください。新しいイベントは随時追加され、登録済みのすべてのエンドポイントに送信されます。

エンドポイントの登録

Webhook エンドポイントは、API を使ってお客様ご自身で登録・管理できます: 登録する前にハンドラーをデプロイしてください。Return Helper はその URL に署名付きの検証リクエストを送信し、30 秒以内に 2xx ステータスが返された場合にのみエンドポイントが保存されます。 登録した各エンドポイントは、アカウントのすべてのイベントを受信します。category と action フィールドを使って、お客様側でフィルタリングしてください。 サンドボックスと本番環境は別々に登録します。通知を受け取りたい各環境で、その環境の認証情報を使って API を呼び出してください。

イベント配信

タイミング — イベントはトリガーアクションの数秒後に届く場合があり、まれに数分後になることがあります。 重複イベント — エンドポイントが同じイベントを複数回受信する場合があります。処理済みの notificationId を追跡して重複を排除してください。notificationId はイベントごとに一意で、すべてのウェブフック通知に含まれるため、それ単体で安定した冪等キーとして使用できます。 イベントの順序 — 配信順序は保証されていません。任意の順序でイベントを処理できるようにハンドラーを設計してください。たとえば、inventoryCreatedがwarehouseMarkShipmentArrivedV2より前に届く場合があります。順序外で受信したイベントで参照されているオブジェクトを取得するには、APIを使用してください。 各イベントにはISO 8601形式のeventTimeフィールドが含まれています。

通知ヘッダー

すべてのWebhookリクエストには以下のヘッダーが含まれています:

旧ヘッダー

以下のヘッダーは引き続きすべての通知で送信され、削除される予定はありません。新規の連携では上表のヘッダーを読み取ってください。
HTTP ヘッダー名は大文字・小文字を区別せず、フレームワークによっては正規化されます。上表は Return Helper が実際に送信する表記です。受信ヘッダー名が小文字化されるフレームワークをお使いの場合は、大文字・小文字を区別せずに照合してください。

署名の検証

ペイロードを処理する前に必ず署名を検証してください。生のリクエストボディを使用してください — フレームワークによるJSONの再シリアライズなどの変換は検証の失敗を引き起こします。
署名キーはReturn Helperから提供されます(Base64エンコードされています)。安全に保管し、公開しないでください。API キーおよびトークンと同じ画面(ユーザーポータル)で確認できます——認証 のスクリーンショットを参照してください。また、Signing Key を取得でプログラムから読み取ることもできます。

詳細な例

以下の受信リクエストがあるとします: ヘッダー:
ボディ(生のJSON、再シリアライズしてはいけません):

ステップバイステップの検証

ステップ1 — ReturnHelper-Signature ヘッダーから署名を抽出する(最後の比較用):
ステップ2 — RETURNHELPER-TRIGGERED-AT ヘッダーからタイムスタンプを抽出する:
ステップ3 — string_to_signを構築する 以下の4つの値を順番に連結します(区切り文字なし):
  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時間停止されます。

共通ボディフィールド

すべての通知ボディはこれらのトップレベルフィールドを共有しています:

通知イベントリファレンス


通知ペイロード

ラベル結果

返品ラベルリクエストが完了したとき(成功または失敗)に送信されます。
ラベルをシステム内の配送にマッチさせるには必ずshipmentIdを使用してください — labelIdを使用しないでください。まれにキャリアの障害により、同じshipmentIdに対して新しいラベル(新しいlabelId)が発行されることがあります。
category: labelGenerated / action: labelGenerated labelの主要フィールド:

地域別ラベルURL

regionsは、labelUrlと同じラベルファイルの別のURLを提供します。その地域でラベルをダウンロードまたは印刷する場合に使用してください。
  • 各値はlabelUrlと同じPDFを指します。異なるのはホストのみです。
  • すべてのアカウントに含まれます。設定は不要です。
  • labelGeneratedイベントにのみ含まれます。APIレスポンスや他のWebhookイベントに含まれるラベルURLは、labelUrlのホストのみを使用します。地域別URLが必要な場合は、このイベントから保存してください。
  • labelUrlがnullの場合(ラベルリクエストが失敗した場合)、regionsは{}になります。
  • 認識できないキーは無視してください。必要なキーがない場合はlabelUrlを使用してください。
成功例:
失敗例:

倉庫配送到着(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の主要フィールド:

リコールステータス更新

Recall はまもなく終了します。Return Helper の香港倉庫へ在庫を送るには、destinationType: RH_WAREHOUSE で Consolidate Shipping Order を作成してください。
リコール追跡番号が更新されるか、集荷ステータスが変更されたときに送信されます。 category: recall / action: recallUpdateStatus recallUpdateTypeStatusの値:

再送ステータス更新

再送追跡番号が更新されるか、再送が完了または失敗したときに送信されます。 category: resend / action: updateResendStatus トップレベルのペイロードフィールド: resendの主要フィールド: resendShipmentListの各エントリの主要フィールド:
resendShipmentList には常に 1 件のエントリのみが含まれます——1 つの resend に対して resend shipment は必ず 1 つだけです。resendShipmentList[0] として読み取ってください。
trackingNumber はトップレベルのフィールドでは ありません。再送配送の中にあります:resendShipmentList[0].trackingNumber。
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の各アイテム:
箱には RMA 明細、FNSKU 明細、またはその両方が入ります。RMA 明細のない箱も一覧に含まれます。

統合配送発送済み

倉庫が統合配送をキャリアに発送したときに送信されます。 category: consolidateShippingShipmentSent / action: consolidateShippingShipmentSent shipmentの主要フィールド:

統合配送AWB更新済み

統合配送の航空貨物運送状番号が更新されたときに送信されます。 category: consolidateShippingShipmentShipped / action: consolidateShippingShipmentShipped shipmentオブジェクトは、更新されたawbフィールドを含む、統合配送発送済みと同じ構造に従います。 RH_WAREHOUSE の注文では、倉庫が AWB を記録したときにこのイベントが送信されます。consolidateShippingShipmentStatus は IN_TRANSIT で、この時点ではまだ請求されません。Shipment は到着時に請求され、統合配送到着済み で通知されます。

統合配送到着済み

RH_WAREHOUSE 注文の Shipment が Return Helper 倉庫に到着し、送料が請求されたときに、Shipment ごとに 1 回送信されます。 category: consolidateShippingShipmentArrived / action: consolidateShippingShipmentArrived / version: 202609
バージョン 202609 はオプトインです。受信するには Return Helper カスタマーサービスにお問い合わせください。
明細を含む Shipment が 3 件ある注文では、1/3、2/3、3/3 の 3 件のイベントが送信されます。 order のフィールド: バージョン 202609 には shippingMethod は含まれません。 shipmentList の各項目: consolidateShippingInventoryList の各項目:

統合注文完了

統合注文のすべての明細が出荷されたときに送信されます。RH_WAREHOUSE の注文では、明細を含むすべての Shipment も到着している必要があり、このイベントは注文の最後の統合配送到着済みの後に送信されます。 category: consolidateShippingOrderCompleted / action: consolidateShippingOrderCompleted orderオブジェクトは、boxListと在庫詳細を含む完全なshipmentListを含む、統合配送すべて梱包済みと同じ構造に従います。

統合注文キャンセル

倉庫が統合配送注文を強制キャンセルしたときに送信されます。 category: consolidateShippingOrderCancelled / action: consolidateShippingOrderCancelled orderの主要フィールド:

取引追加済み

お客様のアカウントに取引が計上されるたびに 1 回送信されます。対象は課金、返金、再課金、トップアップです。
apiTransaction.notes には通常、その取引の対象となった操作の説明が含まれるため、headId を解決しなくても取引の内容を把握できます。
category: transaction / action: addTransaction / version: 202610 apiTransactionの主要フィールド: apiBalanceの主要フィールド:
balance はこの取引が計上された時点の値であり、現在の残高ではありません。イベントは順不同で届く場合があります。現在の残高は API アカウント残高を取得で取得してください。

headId が指すもの

下表で transactionType を探し、記載のイベントまたはレスポンスで取得済みの ID と headId を照合してください。headId は常に文字列です。返金または再課金の headId は、調整対象の課金と同じです。 ¹ rsl は生成に失敗したラベルの返金です。headId は labelId ですが、失敗したラベルが購入者返品ラベルの場合は returnRequestId です。
  • すべての取引が送信されます。個別のタイプのみを購読することはできません。transactionType と amount の符号で処理を分岐してください。
  • 新しい transactionType の値が追加される場合があります。認識できないタイプでも amount と balance は記録し、イベントを拒否しないでください。
  • 1 つの配送に複数のラベルが存在することがあるため、csl も複数になる場合があります。labelId と shipmentId の対応付けにはラベル結果を使用してください。
  • createOn は取引が計上された日時、eventTime は通知が送信された日時です。