開発者

PUT/tcr/v2/brand/{brandId}/externalVetting

既存の審査結果をインポートする

対応プロバイダーの既存の審査結果をブランドに関連付けます。

このページの内容
  1. アカウントが所有するメッセージングブランドを使用する
  2. プロバイダーの既存の審査結果を使用する
  3. インポートを準備する
  4. 結果を一度だけインポートする
  5. 既存の請求を理解する
  6. 実際の審査結果を確認する
  7. 同じ操作のリクエストを再試行する

アカウントが所有するメッセージングブランドを使用する

許可された送信元IPアドレスから、HTTPS経由で有効なAPIアカウントを使用してください。Basic認証とBearer認証に対応しています。ブランドIDはそのアカウントに属している必要があります。プロバイダーのトークン、ブランドの識別情報、返されたレポートは非公開で管理してください。

プロバイダーの既存の審査結果を使用する

PUTを使用して、対応プロバイダーの既存の審査結果をブランドに関連付けます。新たな審査を注文する操作ではありません。正しいプロバイダーの取引IDと、必要な確認トークンをそのプロバイダーから直接取得し、レポートが同一の事業者に対するものであることを確認してください。

AUTHPLUSはこのインポート手順に対応していません。プロバイダー固有の照合ルールは引き続き適用されます。インポートをリクエストしても、これらのルールが免除されるわけではなく、すべてのキャンペーン用途の適格条件を満たすことが保証されるわけでもありません。

インポートを準備する

外部審査結果のインポート用フィールド
フィールド値
evpId対応プロバイダーのID。1–10文字。
vettingIdプロバイダーが発行した実際の審査取引識別子。最大255文字です。ブランドIDで代用したり、架空の識別子を作成したりしないでください。
vettingTokenプロバイダーが要求する場合の確認トークン。最大65535文字です。機密情報として扱い、プロバイダーが要求しない場合は省略してください。

プロバイダーの実際の値を使ってvetting-import.jsonを作成してください。レスポンス専用のスコア、ステータス、タイムスタンプのフィールドを、結果を変更できるかのように送信しないでください。

結果を一度だけインポートする

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @vetting-import.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"

既存の請求を理解する

このプロキシは、新しくインポートした結果を新規の有料注文として記録しません。ただし、以前に注文した審査がキャンセルされるわけではありません。同じvettingIdに対して結果待ちまたは課金待ちの注文がすでにある場合、ACTIVEまたはFAILEDの結果をインポートすると、その注文に保存されている料金が精算されることがあります。この同期処理の分岐では、課金済みのレコードに再び課金することはありません。

実際の審査結果を確認する

成功したHTTPレスポンスに、処理待ちの審査レコードが含まれることがあります。そのvettingIdを保持し、vettingStatus、理由、スコア、有効開始日と有効期限を、取得できる範囲で確認してください。PENDINGとUNSCOREについては、引き続き状況を確認する必要があります。ACTIVE、FAILED、EXPIREDは、それぞれ異なる結果を表します。HTTPでリクエストが受理されたことだけでは、良好なスコアやキャンペーンの適格性は確認できません。

記録の状況を追跡するには、次の項目を使用してください:外部審査のステータス。最終状態の結果を取得またはインポートすると、以前の有料注文が精算されることがあります。既存の未払い料金が請求されないとは限りません。

同じ操作のリクエストを再試行する

実行する操作ごとに一つのIdempotency-Keyを使用し、メソッド、パス、クエリ、本文のバイト列をそのまま保持してください。キーには、空白を含まない印字可能なASCII文字を1–128文字使用できます。処理中のリクエストと重複する場合、Retry-Afterを伴う409が返されることがあります。完了済みのリクエストでは、エラーを含め、保存されたレスポンスが再送されます。レート制限を守ってください。

通信障害の後に、キャッシュされた502が返されることがあります。requestIdを含むキャッシュされた500は、レジストリが操作を受理したものの、ローカルでの永続化または課金に失敗したことを意味する場合があります。リクエストIDを保持し、現在のレコードを確認して、新しいキーを使用する前にサポートと状況を照合・調整してください。エラーが発生したからといって、注文が存在しないと判断しないでください。