前提条件
Return Helper APIと連携する前に、以下を準備してください:- API認証情報 — 認証セクションを参照してください。
- Return Helperからの非同期イベントを受信するためのWebhook通知エンドポイント。通知エンドポイントが提供されていない場合、ラベル結果や倉庫イベントを受信できません。
- このガイドを読み、主な返品フローを理解してください。
返品フローの概要
典型的な返品には3つの段階があります:- 倉庫到着前 — 返品配送(Return Shipment)を作成し、配送ラベルを受け取ります。
- 倉庫到着 — 荷物がスキャンされ、画像がアップロードされ、配送が返品在庫(Return Inventory)レコードになります。
- 到着後の処理 — 在庫をどのように処理するかを倉庫に指示します(廃棄、再送、リコール、付加価値サービス(VAS)など)。
返品ラベルのリクエスト
ラベルの作成は非同期です。フローは以下の通りです:- 返品配送(Return Shipment)の作成を呼び出して、返品配送(Return Shipment)レコードを作成し、ラベルリクエストをキューに入れます。
- Return Helperがラベルを生成し、ラベル通知イベントを通じてWebhook通知エンドポイントに結果を配信します。
RMA(返品商品承認)
配送がReturn Helper倉庫に入ると、グローバルに一意なRMAが割り当てられます。Return Helperは、以下の2つの理由から、配送追跡番号の代わりにRMAを主要な通信識別子として使用しています:- 追跡番号はキャリア間で重複する場合があります。または同じキャリア内でも重複することがあります。
- VASによって荷物が分割された場合、各結果の荷物は独自のRMAを受け取ります。
TWN-20-230101-D12345-36
分割RMAフォーマット(VAS分割後):
TWN-20-230101-D12345-01-36
倉庫到着時の返品在庫(Return Inventory)
返品配送(Return Shipment)が倉庫に到着すると、受領済みとしてマークされ、1つ以上の**返品在庫(Return Inventory)**レコードに変換されます。各レコードには一意のreturnInventoryIdが付与されます。
タイプ1 — 販売者が開始した配送
- 販売者がAPIを通じて配送を作成し、ラベルを提供しました。
- 倉庫が受領済みとしてマーク → warehouseMarkShipmentArrivedV2 Webhookが送信され、続いてinventoryCreated(
returnInventoryIdを含む)が送信されます。 - 単一のラベルが複数の荷物をカバーしている場合、各荷物は同じ
shipmentIdとreturnRequestIdを共有する別々の返品在庫(Return Inventory)レコードになります。在庫ごとに1つのinventoryCreatedイベントが送信されます。 - 在庫画像は次にアップロードされ、changeLineItemImageを通じて配信されます。
タイプ2 — 販売者に割り当てられた不明な配送
- 販売者が作成したレコードなしに配送が到着しましたが、販売者のものとして識別されました。
- assignUnknown Webhookが送信され、返品在庫(Return Inventory)ペイロード、
returnInventoryId、shipmentId、returnRequestIdが含まれます。 - 荷物に複数のアイテムが含まれている場合、複数のinventoryCreatedイベントが続く場合があります。
- 割り当て前にキャプチャされた画像はassignUnknownに含まれています;その後の変更はchangeLineItemImageを通じて届きます。
在庫画像
画像がアップロードされた(または画像リストが変更された)場合、changeLineItemImage Webhookが送信され、画像URLリストが含まれます。処理指示
返品在庫(Return Inventory)レコードが存在したら、倉庫にどのように処理するかを指示します:廃棄(Dispose)
廃棄処理タイプで返品在庫(Return Inventory)処理の更新を呼び出します。指示を取り消すには返品在庫(Return Inventory)処理のキャンセルを使用します。保留(Hold)
保留処理タイプで返品在庫(Return Inventory)処理の更新を呼び出します。再送(Resend)
returnInventoryId値のリストで再送の作成を呼び出します。- resend Webhook通知を通じて再送追跡番号を受け取ります。
- 再送が不要になった場合は再送のキャンセルを呼び出します。
リコール
- 最大100個の
returnInventoryId値で返品在庫(Return Inventory)IDによるリコールの作成を呼び出します。 - 追跡の更新と集荷ステータスの変更はrecall Webhook通知を通じて配信されます。
付加価値サービス(VAS)
カスタムフィールド
カスタムフィールドを使用すると、返品に任意のキーと値のメタデータを付加できます。これらはReturn Helperによって保存されますが、処理はされません — 関連するWebhook通知でそのまま返されます。- タイプ:
Dictionary<string, string> - 返品ごとに最大24個のカスタムフィールド。
FBA(フルフィルメント by Amazon)返品
顧客はFBA商品をReturn Helper倉庫に送って処理(再入荷、補充、リコール、廃棄など)を受けることができます。 一般的なFBAワークフロー:- FBA配送の作成を呼び出してReturn Helperに通知し、商品を倉庫に送ります。
- 配送が受け取られ、
fnskuとquantityでFBA在庫として保管され、Webhookを通じて配信されます。 - FNA倉庫在庫リストの取得で既存のFBA在庫を確認します。
- FBA指示の作成を通じて指示を作成します(補充には現在APIで提供されていない追加の配送情報が必要です)。
- Return Helperが指示を処理し、Webhookを通じて結果を通知します。
- 関連するFBA指示詳細取得エンドポイント(リコール、廃棄、再入荷、その他)を通じて指示ステータスを確認します。
- FBA配送の一覧を使用して日付範囲内の過去の配送を取得し、
fbaShipmentId値を収集します。 - FBA配送アイテムリストの取得を呼び出して、配送ごとのアイテム、FNSKU、数量を取得します。
- FNSKUでFBA倉庫在庫リストの取得を使用して現在の在庫を確認します。
- FBA指示の一覧を使用して過去の指示を検索します。
- 指示ごとにFBA指示アイテムリストの取得を使用してラインアイテムの詳細を取得します。
歴史的なデータの取得
このセクションは、APIに移行している既存のReturn Helper Portalユーザー向けです。ゼロから連携している場合、必要なすべてのデータは通常のAPI呼び出しとWebhookイベントを通じて交換されます — 歴史的なデータを取得する必要はありません。
レスポンス構造
すべてのAPIレスポンスには、結果ステータスを示すmetaオブジェクトが含まれています。
成功レスポンス(status: 200):
warehouseId):
200以外のstatus値は、リクエストが正常に完了しなかったことを意味します。errorCodeとerrorフィールドが詳細を提供します。