> ## 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 历史：会话与重新验证

> Didit 可检索某个用户实体关联的全部验证会话，查看各功能的详细结果，触发重新验证，并导出合规报告。



KYC History Prompt
        将提示词复制到剪贴板



      
      

\<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 实体。您可以检索完整历史记录、查看单个会话的结果、触发重新验证，并导出合规报告。## 列出用户的所有会话按 `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"
```决策结果包括：- 各项功能的结果（证件、活体检测、人脸比对、AML、地址证明、NFC 等）
- 提取的证件数据和图片（签名 URL）
- AML 命中记录及匹配分数和风险分数
- 设备与 IP 分析以及设备信息
- 审核员备注和人工操作记录完整的数据结构请参阅[检索会话](https://docs.didit.me/zh/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` 映射会更新为新的结果。## 重新提交与新建会话| 场景 | 使用方式 |
| - | - |
| 用户会话因可修复的问题被拒绝（证件模糊、光线不佳） | [重新提交](https://docs.didit.me/zh/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
```如需将用户的完整历史记录汇总到一个文件中，请下载[用户历史 PDF](https://docs.didit.me/zh/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/`：生成可共享的 token。
- `POST /v3/session/import-shared/`：在接收方导入共享会话。完整流程请参阅[可复用 KYC](https://docs.didit.me/zh/core-technology/reusable-kyc/overview.md)。## 基于历史记录的工作流利用会话历史做出更智能的合规决策：- 如果用户在 N 天内已有通过的活体检测，**跳过**相应步骤。
- 如果用户最近一次会话被拒绝，**要求**额外检查。
- 当用户的会话数量异常激增时，**标记**该用户。
- 通过[持续监控](https://docs.didit.me/zh/core-technology/aml-screening/continuous-monitoring-aml-screening.md)功能**监控**持续进行的 AML 重扫。## 后续步骤> [card] [数据模型](https://docs.didit.me/zh/entities/users/data-model.md)
>
> 了解 features 映射和计数器的计算方式。> [card] [检索会话](https://docs.didit.me/zh/sessions-api/retrieve-session.md)
>
> 完整的会话决策数据结构。> [card] [可复用 KYC](https://docs.didit.me/zh/core-technology/reusable-kyc/overview.md)
>
> 在多个应用之间复用已验证的数据。


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