ブランドの審査結果を確認する

確認するブランドを選択する

ご自身のアカウントのブランド ID を使用してください。ある事業者の審査を別の事業者の審査と取り違えないよう、取得した審査記録とブランド ID を一緒に保持してください。別のアカウントの識別子は使用しないでください。

既存の審査を追跡する

次の項目が含まれている場合は保持してください：vettingId、evpId、vettingClass、および vettingStatus。現在の同期処理では、PENDING と UNSCORE を引き続き確認が必要な結果として扱い、ACTIVE と FAILED を精算の対象となる最終結果として扱います。追加対応の要否を判断する前に、返された詳細を確認してください。リストが空であるというだけでは、以前の申請がレジストリに届かなかった証拠にはなりません。

以前の注文に対する料金を理解する

ステータスを確認しても、別の審査が注文されることはありません。ただし、完了した結果を照合し、以前の課金対象の審査リクエストに付随する料金を精算する場合があります。これには、該当する場合の審査失敗時の料金も含まれます。注文時に確認した価格と条件を使用してください。古い例やステータスのレスポンスから現在の価格を推測しないでください。

再注文せずに読み取りを再試行する

一時的な障害の場合は、ブランド ID と既知の審査 ID を保持し、Retry-After に従って、バックオフを適用してこの読み取りを再試行してください。ステータスの照会が失敗した、または想定外の本文が返されたという理由だけで、新たに審査を注文しないでください。不整合が解消しない場合は、認証済みのサポート窓口を通じて、関連する参照 ID を添えて MultiTEL にお問い合わせください。

登録手順を区別する

審査によってブランドの審査結果が確定します。キャンペーンの適格性確認、キャンペーン登録、電話番号の割り当ては、それぞれ別の手順です。メッセージを送信する前に、それらの現在のステータスと要件を確認してください。

リクエスト

許可された送信元 IP アドレスから、HTTPS 経由で有効な API アカウントを使用してください。レジストリの認証情報ではなく、ご自身のアカウントの認証情報を使用してください。ブランドは、認証されたアカウントに関連付けられている必要があります。

パスにブランド ID を指定し、必須の vettingStatus クエリフィルターを付けて GET リクエストを送信します。レビュー済みのスキーマでは、ステータスの配列が定義されています。この例では、ACTIVE の値を単独で指定してリクエストします。このガイドでは、複数値のエンコード方法や、フィルターなしのリクエストをプロバイダーが受け付けるかどうかは確認されていません。リクエスト本文は不要です。

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting?vettingStatus=ACTIVE"

レスポンス

現在のルートは、従来の v3 レスポンスエンベロープを使用せず、レジストリの HTTP ステータスと本文をそのまま保持します。省略した架空の配列は、ローカルの同期処理で使用されるフィールドを示しています。実際に取得したレジストリのレスポンスではなく、完全なスキーマを保証するものでもありません。記録を読み取る前に、HTTP ステータスと JSON を確認してください。各 vettingId は、選択したブランドと一緒に保持してください。

レスポンスの構造を示す例です。実際のアカウントデータや現在の見積もりではありません。

[
  {
    "vettingId": "example-vetting-id",
    "evpId": "example-review-provider",
    "vettingClass": "STANDARD",
    "vettingStatus": "ACTIVE"
  }
]

エラー

• 401: アカウント認証に失敗しました。認証情報、API が有効になっているかどうか、および適用される送信元 IP の制限を確認してください。
• 404: ブランドがこのアカウントに関連付けられていないか、レジストリで見つかりませんでした。アカウントの所有関係に基づく拒否は、レジストリへのリクエスト前に行われます。
• 429: アカウントまたはレジストリのリクエスト上限に達しました。Retry-After に従い、バックオフを適用してください。
• 502/503: 通信、レジストリ、リクエスト制限機構、またはローカル処理を利用できません。エラーが発生しただけでは、以前の審査リクエストが失敗したと断定できません。

利用可能性と副作用

• この GET は、新たな審査を注文しません。レジストリの結果を取得し、リクエストの監査記録を書き込み、保存済みの結果を同期します。
• 完了した結果を読み取ると、以前に行った課金対象の審査注文の料金が精算される場合があります。審査が失敗した場合も、該当する失敗時の料金が発生する可能性があります。注文時に価格と条件を確認してください。この読み取りは見積もりではありません。
• この GET で新たに検出され、取り込まれた記録は、新規の課金対象注文として自動的に分類されるわけではありません。
• 審査結果が成功または ACTIVE であっても、キャンペーンの承認、電話番号の割り当て、またはメッセージ送信の許可を意味するものではありません。