共有セッションインポートAPI：再利用可能なKYC・KYB

このセッションに設定された認証機能のリストで、表示名で示されます。ID_VERIFICATION、NFC、LIVENESS、FACE_MATCH、POA、PHONE、EMAIL_VERIFICATION、AML、IP_ANALYSIS、DATABASE_VALIDATION、QUESTIONNAIRE、AGE_ESTIMATION、FACE_SEARCH、GEOLOCATION（位置情報認証）があります（法人確認 (KYB)のセッションではKYBの機能セットであるKYB_REGISTRY、KYB_DOCUMENTS、KYB_KEY_PEOPLE、AML、PHONE、EMAIL_VERIFICATION、IP_ANALYSIS、QUESTIONNAIREを使用します）。include=eventsを指定すると、各エントリはプレーンな文字列ではなくオブジェクト{feature, node_id}になり、メール機能の名前が変わります。イベントモードでは、ここで使用されるEMAIL_VERIFICATIONではなくEMAILとして表示されます。

本人確認(OCR)レポートの配列。ワークフローグラフ内の本人確認書類ステップによって生成されます。常にJSON配列です。id_verifications[0]を読み取り、ワークフローで複数の本人確認を実行できる場合(たとえば一次確認に加えて追加確認を行う場合)は反復処理してください。少なくとも1つの本人確認ステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、抽出された書類フィールド、画像URL、品質スコア、MRZ、住所の解析結果、セッション間の一致、warnings[]を含みます。

NFC / ePassportレポートの配列。ワークフローグラフ内のNFCステップによって生成されます。これは常にJSON配列であり、単一のnfcオブジェクトになることはありません。nfc_verifications[0]を読み取り、ワークフローでNFCを複数回実行できる場合は反復処理してください。少なくとも1つのNFCステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、chip_protocol、chip_data、authenticity(SOD + DGの完全性)、certificate_summary、warnings[]を含みます。日本のマイナンバーカードはICAO 9303ではなくJPKIを通じて読み取られます。その要素はchip_protocol: "jpki"を持ち、証跡をjpkiの下に格納し、ICAOのフィールドはnullのままです。NFCステップが提示される前にバイパスされた場合(チップのない書類、証明書の欠落、NFC機能の報告なし、読み取れないMRZキー、マイナンバーカードでJPKIが利用できない場合)、この値はnullのままで、nfc_skip_reasonがその理由を示します。ステップ自体でのスキップ(ユーザーがスキップをタップした場合、またはスキャン時にリーダーが利用できないと判明した場合)でも、is_nfc_skipped: trueを含むレポートが生成されます。

ライブネスレポートの配列。ワークフローグラフ内のライブネスステップによって生成されます。常にJSON配列であり、単一のlivenessオブジェクトになることはありません。少なくとも1つのライブネスステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、method、score、reference_image、video_url、任意のage_estimation、セッション間のmatches[]、warnings[]を含みます。

顔照合レポートの配列。ワークフローグラフ内の顔照合ステップによって生成されます。常にJSON配列であり、単一のface_matchオブジェクトになることはありません。少なくとも1つの顔照合ステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、類似度のscore、source_image、target_image、warnings[]を含みます。

電話番号検証レポートの配列。常にJSON配列であり、単一のphoneオブジェクトになることはありません。少なくとも1つの電話番号ステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、電話番号と国のメタデータ、lifecycle[]、matches[]、warnings[]を含みます。

メールアドレス認証レポートの配列。常にJSON配列であり、単一のemailオブジェクトになることはありません。少なくとも1つのメールステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、メールアドレス、漏洩データ、lifecycle[]、matches[]、warnings[]を含みます。

住所証明(POA)レポートの配列。常にJSON配列であり、単一のpoaオブジェクトになることはありません。少なくとも1つのPOAステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、書類ファイルのURL、発行者、日付、解析済みの住所、warnings[]を含みます。

ワークフローノードごとにグループ化されたDocument AIレポート。常にJSON配列で、単一のオブジェクトになることはありません。少なくとも1つのDocument AIステップがデータを生成するまではnullです。session_kind = userの場合にのみ含まれます。各項目はノードグループで、集計されたstatus、node_id、書類ごとの結果（設定したフィールドキーをキーとする抽出データ）を格納するitems[]配列、およびwarningsを含みます。

アンケート回答レポートの配列。常にJSON配列であり、単一のquestionnaireオブジェクトになることはありません。少なくとも1つのアンケートステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、アンケートのメタデータ、フォーム要素を含むセクション、ユーザーの回答を含みます。

ユーザー認証および法人確認における銀行口座認証の結果で、銀行口座認証ステップごとに1項目です。ステップが結果を生成するまではnullです。各項目のmethodは口座の認証方法を示します。open_banking（銀行へのサインイン）またはaccount_lookup（口座照会）、フォールバックとしてのstatementまたはmicrodepositsのいずれかで、いずれの試行も評価される前に本人が銀行を使わずに続行した場合（continued_without_bank）はnoneです。詳細は銀行口座認証の方法を参照してください。銀行口座認証は本番環境ではまだ有効化されていないため、有効化されるまで本番環境のセッションではこの値はnullのままです。

ユーザー認証および法人確認における電子署名の結果で、署名者と署名ステップごとに1項目です。ワークフローに電子署名ステップがある場合にのみ存在し、署名者がそのステップに到達するまでは空の配列です。電子署名レポートを参照してください。

AMLスクリーニングレポートの配列。常にJSON配列であり、単一のamlオブジェクトになることはありません。少なくとも1つのAMLステップがデータを生成するまではnullです。各項目は完全なレポートで、node_id、機能レベルのstatus、total_hits、entity_type、hits[]、score、screened_data、is_ongoing_monitoring_enabled、warnings[]を含みます。

デバイス・IP分析レポートの配列。常にJSON配列であり、単一のip_analysisオブジェクトになることはありません。少なくとも1つのIP分析ステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、IPおよび位置情報データ、デバイスフィンガープリント、warnings[]を含みます。(node_id, ip_address, device_fingerprint)が重複するエントリは、サーバー側で重複排除されます。

位置情報検証結果の配列。位置情報検証ステップごとに1件で、そのステップで受理された試行が入ります。位置情報検証ステップがデータを生成するまではnullです。同じステップの以前の試行はgeolocation_attemptsにあります。

このセッションのすべての位置情報検証ステップにおける全試行を古い順に示します。再提出によって置き換えられた試行は含まれません。レスポンス属性でgeolocation_checksを非表示にしているワークフローでは、このリストも非表示になります。

データベース検証レポートの配列：常にJSON配列であり、単一のdatabase_validationオブジェクトになることはありません。少なくとも1つのDB検証ステップがデータを生成するまではnullです。各要素は完全なレポートで、node_id、機能レベルのstatus、screened_data、サービスごとのvalidations[]（それぞれに登録機関のsource_dataを含む）、warnings[]を含みます。screened_dataとsource_dataのフィールドは国によって異なります。

ARG（アルゼンチン）：screened_data: {document_number, selfie, gender, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}。RENAPERの生体顔照合による検証を使用します。書類に性別が記載されていない場合（運転免許証など）、性別は顔分析または名から自動的に推定されます。

BOL（ボリビア）：screened_data: {document_number, date_of_birth, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA（ブラジル）：screened_data: {tax_number, first_name, last_name, date_of_birth}。CPFの照合に成功した場合、source_dataには常に{identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16}が含まれます。成人の照会に成功した場合、これらのフラグはfalseに設定されます。Receita FederalのConsulta CPFサービスは、LGPDにより開示が保留されたデータとともにHTTP 422（18歳未満の未成年者）または451（16歳未満）を返す場合があります。その場合、source_dataでは該当する未成年者フラグがtrueに設定され、上流のHTTPステータスが含まれ、フィールドレベルの検証はno_matchになります。コードの全一覧は、Database Validation Outcome Codesリファレンスのブラジルのセクションを参照してください。

CHL（チリ）：screened_data: {personal_number, first_name, last_name, date_of_birth}。source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL（コロンビア）：screened_data: {document_number, document_type, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI（コスタリカ）：screened_data: {personal_number, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name}

DOM（ドミニカ共和国）：screened_data: {personal_number}。source_data: {identification_number}（有効/無効のみを返します）

ECU（エクアドル）：screened_data: {personal_number, first_name, last_name}。source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP（スペイン）：screened_data: {personal_number, document_type, expiration_date, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM（グアテマラ）：screened_data: {document_number, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name}

HND（ホンジュラス）：screened_data: {document_number, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name}

MEX（メキシコ）：screened_data: {personal_number (CURP), first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}。RENAPOの住民登録を使用します。MEXでは、追加の個別検証として、別途INEの有効性確認サービスも利用できます。

PAN（パナマ）：screened_data: {personal_number, selfie}。source_data: {identification_number}。SIBの生体認証による検証を使用します。

PER（ペルー）：screened_data: {personal_number (DNI), first_name, last_name}。source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY（パラグアイ）：screened_data: {document_number, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name}

SLV（エルサルバドル）：screened_data: {document_number, date_of_birth, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name}

URY（ウルグアイ）：screened_data: {personal_number, date_of_birth, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name}

VEN（ベネズエラ）：screened_data: {document_number, first_name, last_name}。source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

法人登記チェック。session_kind = businessの場合にのみ含まれます。各項目は法人登記のペイロード全体をラップします。

主要人物チェックの集約。session_kind = businessの場合にのみ含まれます。各項目は2つのバケットからなる形式（registry、submitted、ubo_kyc_summary）を使用します。

ワークフローノードごとにグループ化された書類検証チェックです。session_kind = businessの場合にのみ含まれます。

include=resubmissionsを指定した場合にのみ、ユーザーセッションと企業セッションで返されます。再提出リクエストごとに1件のエントリーがあり、古い順に並びます。各エントリーには、リクエスト前に再提出対象のステップが返した結果が含まれるため、以前の提出内容も引き続き参照できます。セッションを削除すると、すべての提出内容が削除されます。