> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# ユーザーのKYC履歴：セッションと再検証

> Userエンティティに紐づくDiditのすべての検証セッションを取得できます。機能ごとの結果の確認、再検証のトリガー、コンプライアンスレポートのエクスポートにも対応しています。



KYC履歴プロンプト
        プロンプトをクリップボードにコピー



      
      

\<pre>

\````# Goal — read a user's full KYC history and trigger re-verification

Every KYC session a user has ever run stays permanently linked to the User entity via `vendor_data`. The session list endpoint is the entry point; the decision endpoint is the detail view.

\## List every session for a user

\```bash
curl -G https://verification.didit.me/v3/sessions/ \
-H "x-api-key: $DIDIT_API_KEY" \
\--data-urlencode "vendor_data=user-42" \
\--data-urlencode "page_size=50"
\```

Response covers every status (approved, declined, in review, abandoned, expired). Paginate with the `next` cursor / `page` param until empty.

\## Inspect a single session decision

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/decision/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

V3 returns plural arrays — always iterate them:

\- `id_verifications[]`
\- `liveness_checks[]`
\- `face_matches[]`
\- `aml_screenings[]`
\- `nfc_verifications[]`
\- `proof_of_address_checks[]`

Never assume V2 singular fields.

\## Trigger re-verification

Annual re-KYC, document expiry, trigger-based re-checks — same pattern: create a new session against the same `vendor_data`. The new session attaches to the existing User entity and updates the `features` map on completion.

\```bash
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow_id": "wf_reverification", "vendor_data": "user-42"}'
\```

\## Fast path — fully verified right now?

The User entity carries a `features` map summarising the **latest** state of each feature across all sessions:

\```bash
curl https://verification.didit.me/v3/users/user-42/ \
-H "x-api-key: $DIDIT_API_KEY"
\# data.features = { id_verification: "APPROVED", liveness: "APPROVED", aml: "IN_REVIEW", ... }
\```

Use `features` for "is the user verified right now?" without iterating every session.

\## Generate a PDF for any session

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/generate-pdf/ \
-H "x-api-key: $DIDIT_API_KEY" \
-o session-report.pdf
\```

\## Generate the full user history PDF

One file with a cover page plus the report of every reportable session (`Approved`, `Declined`, `In Review`, `Kyc Expired`) of the user, capped at the 20 most recent. Same document as Console → User detail → Actions → Download PDF. Synchronous render: use a 120s read timeout.

\```bash
curl --fail https://verification.didit.me/v3/users/user-42/generate-pdf/ \
-H "x-api-key: $DIDIT_API_KEY" \
-o user-history.pdf
\```

404 = no such user in this application; 403 = user has no reportable session yet.

\## Resubmit vs new session

\| Scenario | Use |
\|---|---|
\| Declined for fixable reason (blurry ID, bad lighting) | Resubmit the existing session (re-deliver `url`); the workflow advances through resubmission |
\| Annual / trigger-based re-KYC | Create a brand new session via `POST /v3/session/` |
\| Transaction-rule triggered remediation | The transaction creates a remediation session automatically (`Awaiting User` status) |

\## Share a session with a partner (Reusable KYC)

\```bash
\# Issue a shareable token
curl -X POST https://verification.didit.me/v3/session/$SESSION_ID/share/ \
-H "x-api-key: $DIDIT_API_KEY"

\# Receiver imports the shared session
curl -X POST https://verification.didit.me/v3/session/import-shared/ \
-H "x-api-key: $RECEIVER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"share_token": "..."}'
\```

\## Failure modes

\- `404` on the user — wrong `vendor_data` casing or no sessions yet.
\- Empty `results[]` — no sessions for this `vendor_data` in this application.
\- Stale signed image URLs — re-fetch the decision.
\- Sharing rejected — receiving application must have Reusable KYC enabled.

\## Sources of truth

\- /sessions-api/retrieve-session — V3 decision schema
\- /management-api/users/generate-pdf — full user history PDF
\- /reference/data-models — per-feature plural-array contract
\- /core-technology/reusable-kyc/overview — share / import pattern
\- /entities/users/data-model — features map computation
\- /integration/integration-prompt — canonical end-to-end prompt````

\</pre>



      
      

貼り付け先

ユーザーがこれまでに実行したユーザー認証（KYC）セッションは、すべてそのUserエンティティに永続的に紐付けられます。全履歴の取得、個々のセッション結果の確認、再検証の開始、コンプライアンスレポートのエクスポートが可能です。## ユーザーの全セッションを一覧表示するSessionsの一覧を`vendor_data`でフィルターします。```bash theme={null}
curl -G https://verification.didit.me/v3/sessions/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "vendor_data=user-42" \
  --data-urlencode "page_size=50"
```レスポンスには、ステータスにかかわらずすべてのセッション（承認済み、却下、レビュー中、放棄、期限切れ）が含まれます。## 機能ごとの集計を理解するUserエンティティの`features`マップには、全セッションを通じた各機能の**最新**のステータスが反映されます。```json theme={null}
"features": {
  "id_verification": "APPROVED",
  "liveness": "APPROVED",
  "face_match": "APPROVED",
  "aml": "IN_REVIEW"
}
```「このユーザーは現時点で認証済みか」を確認する最短の方法として、これを使用してください。全セッション、全機能、全結果の履歴を確認するには、セッションを一覧表示し、それぞれの判定を確認します。## 単一のセッションを確認する```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/decision/ \
  -H "x-api-key: YOUR_API_KEY"
```判定には以下が含まれます。- 機能ごとの結果（ID、ライブネス検知、顔照合、AML、POA、NFCなど）
- 抽出された書類データと画像（署名付きURL）
- 一致スコアとリスクスコア付きのAMLヒット
- デバイス・IP分析とデバイスのコンテキスト
- レビュアーのメモと手動アクション完全なスキーマについては、[セッションの取得](https://docs.didit.me/ja/sessions-api/retrieve-session.md)を参照してください。## 再検証をトリガーするユーザーに再検証を求める必要がある場合（例: 年次の再KYC、書類の有効期限切れ、トリガーに基づく再チェック）は、次のようにします。```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "wf_reverification",
    "vendor_data": "user-42"
  }'
```新しいセッションは同じUserエンティティに紐付けられます。完了すると、エンティティの`features`マップが更新され、新しい結果が反映されます。## 再提出と新規セッションの違い| シナリオ | 使用する方法 |
| - | - |
| 修正可能な問題（不鮮明なID、照明不足）によりユーザーのセッションが却下された | [再提出](https://docs.didit.me/ja/console/manual-review.md): 同じセッションで再アップロード |
| 完全な再検証または定期的な再KYC | まったく新しいセッションを作成 |
| 取引ルールによってトリガーされた是正対応 | 取引によって是正用セッションが自動的に作成されます（`AWAITING_USER`ステータス） |## コンプライアンスレポートをエクスポートする監査、SAR、規制当局からのリクエストに対応するため、任意のセッションのPDFを生成できます。```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/generate-pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -o session-report.pdf
```ユーザーの全履歴を1つのファイルにまとめるには、[ユーザー履歴PDF](https://docs.didit.me/ja/management-api/users/generate-pdf.md)をダウンロードします。表紙（プロフィールの概要、機能のステータス、セッションの索引）に続き、レポート対象となる各セッションの完全なレポートが古い順に収録されます。収録数は直近の20件が上限です。```bash theme={null}
curl --fail https://verification.didit.me/v3/users/user-42/generate-pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -o user-history.pdf
```これは、コンソールの*Users → \[user] → Actions → Download PDF*から生成されるものと同じドキュメントです。多数のユーザーにまたがるCSVの一括エクスポートには、*Review & Operations → Export PDF/CSV*にあるアプリケーション全体のエクスポートを使用してください。## セッションを第三者と共有するユーザーの認証結果をパートナーのアプリケーションと共有する必要がある場合（例: 再利用可能なKYCのシナリオ）は、以下を使用します。- `POST /v3/session/{session_id}/share/`: 共有可能なトークンを生成します。
- `POST /v3/session/import-shared/`: 受信側で共有セッションをインポートします。パターン全体については、[再利用可能なKYC](https://docs.didit.me/ja/core-technology/reusable-kyc/overview.md)を参照してください。## 履歴を活用したワークフローセッション履歴を活用して、より的確なコンプライアンス判定を行えます。- ユーザーがN日以内に承認済みのライブネスチェックがすでにある場合は、**ステップをスキップ**します。
- ユーザーの直近のセッションが却下されている場合は、**追加チェックを必須に**します。
- ユーザーのセッション数が予期せず急増した場合は、**フラグを立てる**ようにします。
- [継続的なモニタリング](https://docs.didit.me/ja/core-technology/aml-screening/continuous-monitoring-aml-screening.md)機能により、進行中のAML再スキャンを**監視**します。## 次のステップ> [card] [データモデル](https://docs.didit.me/ja/entities/users/data-model.md)
>
> featuresマップとカウンターの計算方法。> [card] [セッションの取得](https://docs.didit.me/ja/sessions-api/retrieve-session.md)
>
> セッション判定の完全なスキーマ。> [card] [再利用可能なKYC](https://docs.didit.me/ja/core-technology/reusable-kyc/overview.md)
>
> 認証済みデータをアプリケーション間で再利用します。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.