メインコンテンツへスキップ
電話番号検証レポートには、電話番号OTP認証の結果がすべて記録されます。コードの送信先、処理を担当したキャリアとチャネル、要した試行回数、番号が使い捨てかVoIPか、ブロックリストや他のユーザーのセッションとのセッション横断的な一致の有無が含まれます。 このページでは、判定エンドポイントが返すJSONの構造を説明します。検証済みの各番号について、OTPの結果、キャリアのメタデータ、リスクフラグを解析する際に参照してください。
OTPの結果、キャリアのメタデータ、リスクフラグを表示したDiditの電話番号検証レポート

概要

電話番号レポートは、ワークフローのノードが電話番号検証機能を実行するたびに生成されます。各レポートは1つの電話番号に対する1回のOTP認証を表し、次の情報を含みます。
  • プレフィックス、国内番号、完全なE.164形式に分解した電話番号と、ISO国コードおよび国名。
  • 宛先ネットワークから取得したキャリアのメタデータ(name、type)。
  • 回線種別の分析から導出したブール値のリスクフラグ(is_disposable、is_virtual)。
  • 実際に使用された配信チャネル(verification_method)と、OTP送信の試行回数。
  • すべての送信、再試行、配信イベント、コード確認の試行を時系列で記録したlifecycle[]ログ。
  • 同じ番号が他のセッション(KYC、KYB、スタンドアロンのAPI検証を問わず、ステータスも問わない)またはブロックリストに存在する場合にそれを示すmatches[]配列。
  • 検証中に発生したリスクイベントを示すwarnings[]配列(電話番号検証の警告を参照)。
  • レポートを生成したワークフローグラフのノードを識別するnode_id(V3セッションのみ)。
ホスト型検証フローでは、DiditがOTPのやり取りを代行します。APIによる直接連携の場合、同じフローは2回の呼び出しで構成されます。コードを配信するPOST /v3/phone/send/と、ユーザーの入力を検証するPOST /v3/phone/check/です。保留中のOTPは最初の送信から5分間有効です(再試行しても有効期間は延長されません)。ワークフローのセッションでは、デフォルトでユーザーにOTP送信の試行が2回(phone_max_retries)、コード入力の試行が2回(phone_max_check_attempts)与えられます。いずれもワークフローのノードごとに調整できます。どちらかの上限に達すると、ステップはVERIFICATION_CODE_ATTEMPTS_EXCEEDEDとともにDeclinedとして確定します。スタンドアロンの電話番号APIでは、認証1件あたりコード入力の試行が3回まで許可されます。

APIレスポンス内での位置

判定エンドポイント(GET /v3/session/{sessionId}/decision/)は、電話番号レポートを複数形の配列キーphone_verificationsの下に返します。この配列には、ワークフローグラフ内の電話番号検証ノードごとに1件のエントリが含まれます。通常は1件ですが、ステップアップフローでは複数件になる場合があります。
値がnullの場合、電話番号検証ステップがまだ実行されていないことを意味します。ワークフローで複数の電話番号を収集する可能性がある場合は、(phone_verifications[0]を読み取るのではなく)配列を反復処理してください。

スキーマ

フィールドごとの正式なスキーマはデータモデルページにあります。

ステータス値

ライフサイクルイベントの種類

lifecycle[]は時系列順に並びます。各イベントにはtype、timestamp、details、および課金対象のfee(該当する場合)が含まれます。 detailsペイロードの内容はイベントの系統によって異なります。
  • 送信イベント(PHONE_VERIFICATION_MESSAGE_SENT、PHONE_VERIFICATION_RETRY_MESSAGE_SENT、PHONE_VERIFICATION_BLOCKED): { status, reason, channel, actual_channel }。statusはSuccess、Retry、Blockedのいずれかです。reasonは送信がブロックされた場合を除きnullです(ブロック時はinvalid_phone_number、repeated_attempts、suspicious、spam、unknown)。channelは要求されたチャネル、actual_channelは実際に配信したチャネルです(例: SMSにフォールバックしたWhatsApp送信)。
  • 配信イベント(PHONE_DELIVERY_DELIVERED、PHONE_DELIVERY_UNDELIVERABLE): { channel, status }。statusはdeliveredまたはundeliverableです。
  • チェックイベント(VALID_CODE_ENTERED、INVALID_CODE_ENTERED): { code_tried, status }。statusはApproved、Declined、Failed、Expired or Not Foundのいずれかです。
  • 最終ステータスイベント: nullです。ただしPHONE_VERIFICATION_DECLINED / PHONE_VERIFICATION_IN_REVIEWは例外で、{ "reason": "<risk code>" }(例: PHONE_NUMBER_IN_BLOCKLIST)を含みます。
送信イベントのfeeは、その送信の合計料金です。キャリアまたはWhatsAppの料金に$0.02のDidit手数料を加えた金額で、[自社のWhatsApp Business番号](/ja/core-technology/phone-verification/overview#自社の番号からwhatsappコードを送信する)から送信したWhatsAppコードの場合は$0.02のDidit手数料のみです。配信が確認されるまでは見積もり料金で、確認後は実際の請求額になります。無料が保証されるのはBlockedの送信のみです。それ以外の送信は、配信が一度も確認されなかった場合やメッセージが配信不能だった場合でも、検証が確定または期限切れになった時点で課金されます。配信、チェック、ステータスの各イベントは常にfee: 0です。

セッション間の一致

matches[]には、同じアプリケーション内で同じ番号が使用された他のセッションが記録されます。対象はKYC、KYB、スタンドアロンAPIによる検証のすべてで、ステータスは問いません。さらに、Management APIのリストで設定したブロックリストへの該当も含まれます。現在のセッションと同じvendor_dataを持つセッションは除外され(同一のエンドユーザーが自分自身と一致することはありません)、配列は最大5件までです。番号がブロックリストに登録されているものの、一致したセッションのいずれもブロックリストに登録されていない場合は、source: "list_entry"を持つ合成エントリ(セッション関連のフィールドはすべてnull)が配列の先頭に追加されます。

例

承認済み (WhatsApp OTP、携帯電話キャリア)

却下 (ブロックリストに登録されたVoIP番号)

ユーザーは有効なOTPを入力しましたが、確定処理で番号がアプリケーションのブロックリストに登録されていることが判明し(自動却下)、VoIPの回線種別にもフラグが付けられました(voip_number_actionはNO_ACTIONのままのため、informationとして記録されます)。一致したセッションのいずれもブロックリストに登録されていないため、ブロックリストへの該当は合成されたlist_entryの一致として表示されます。

関連情報

最終更新日 2026年11月1日