correlationId + meta + payload — エラーハンドリング を参照）を使用します。エラーが発生した場合、meta.errorCode が機械可読のエラーキーになります。本ページでは User API と Public API が返却し得るすべての値を列挙します。
このページの読み方
Wire HTTP 列はレスポンスが実際に届く際の HTTP ステータスです。meta.status 列はボディ内のアプリケーションレベルのステータスです。
meta.errorCode 列はクライアントコードで分岐に使用する値です。
meta.error 列は各エラーの詳細の形を表します。
本 API のほとんどのエラー経路は HTTP 200 を返し、論理的なステータスを meta.status に載せます（ソフトエラーの慣習）。少数のケースでは実際の HTTP 400/401/403/409 を返します — これらは API 自身のレスポンスエンベロープが適用される前に発生するか、本来の HTTP の意味を表しているためです。
バリデーション失敗
ほぼすべての書き込みエンドポイントは FluentValidation を通過します。ここで捕捉されたもの — 必須フィールドの欠落、値の範囲外、無効な国コード、バッチサイズ超過、Custom(...) チェックで表現された業務ルール違反など — はすべて 1 つのエラーコードに集約されます：
サンプルレスポンスボディ：
meta.error を確認してください — キーがどのフィールドが誤っているかを示します。
業務ルール・リソースエラー
リクエストは構造的に有効でも、データの現在の状態、アカウント、あるいはサポートインフラストラクチャと矛盾する場合に、業務ロジックから送出されます。各エラーは異なるerrorCode を持つため、分岐処理が可能です。
認証・アクセス制御失敗
これらはソフトエラーではありません。通常のリクエストパイプラインの前（または外）で生成されるため、実際の HTTP ステータスコードで届きます。競合・未検出
頻度は低いですが発生し得ます：冪等性キーの失敗
以下は、書き込み系エンドポイントでx-returnhelper-idempotency-key ヘッダーを送信した場合に適用され、実際の HTTP ステータスコードで返ります。
キーのスコープは 1 つのアカウントと 1 つの HTTP メソッド・ルートの組み合わせです。そのため、同じキーの値を別のエンドポイントで使っても衝突しません。
クライアント側の推奨処理
擬似コード：correlationId はすべてのレスポンスに含まれます。必ずログに記録してください — Return Helper のサポートが内部システムで特定のリクエストを追跡する手がかりになります。
各エラーコードの定義場所
本ページに掲載しているエラーコードはReturnRequestApiModel.RrException 名前空間の RrErrorCode 定数に由来します。本ページに記載のない errorCode 値に遭遇した場合は、未文書化の内部エラーとして扱い、correlationId とともにサポートへご報告ください。