> ## 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.

# Historique KYC utilisateur : sessions et revérification

> Consultez l'historique des sessions Didit d'un utilisateur, inspectez les résultats, lancez une revérification et exportez les rapports de conformité.



Prompt d'historique KYC
        Copier le prompt dans le presse-papiers



      
      

\<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>



      
      

Coller dans

Chaque session de vérification des utilisateurs (KYC) qu'un utilisateur a effectuée reste liée de façon permanente à son entité User. Vous pouvez récupérer l'historique complet, inspecter les résultats de chaque session, déclencher une revérification et exporter des rapports de conformité.## Lister toutes les sessions d'un utilisateurFiltrez la liste des sessions par `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"
```La réponse inclut toutes les sessions, quel que soit leur statut : approuvée, refusée, en cours d'examen, abandonnée ou expirée.## Comprendre les agrégats des fonctionnalitésLa carte `features` de l'entité User reflète le statut **le plus récent** de chaque fonctionnalité, toutes sessions confondues :```json theme={null}
"features": {
  "id_verification": "APPROVED",
  "liveness": "APPROVED",
  "face_match": "APPROVED",
  "aml": "IN_REVIEW"
}
```Utilisez-la comme chemin rapide pour savoir si l'utilisateur est vérifié actuellement. Pour l'historique complet (toutes les sessions, toutes les fonctionnalités, tous les résultats), listez les sessions et examinez chaque décision.## Inspecter une seule session```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/decision/ \
  -H "x-api-key: YOUR_API_KEY"
```La décision comprend :- Les résultats par fonctionnalité (ID, détection du vivant, correspondance faciale, AML, POA, NFC, etc.)
- Les données extraites du document et les images (URL signées)
- Les correspondances AML, avec leurs scores de correspondance et de risque
- L'analyse de l'appareil et de l'IP, ainsi que le contexte de l'appareil
- Les notes du réviseur et les actions manuellesConsultez [récupérer une session](https://docs.didit.me/fr/sessions-api/retrieve-session.md) pour le schéma complet.## Déclencher une revérificationLorsque vous devez demander à un utilisateur de se vérifier à nouveau (par exemple pour un re-KYC annuel, une expiration de document ou une revérification déclenchée par un événement) :```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"
  }'
```La nouvelle session est rattachée à la même entité User. À la fin de la vérification, la carte `features` de l'entité est mise à jour avec les nouveaux résultats.## Nouvelle soumission ou nouvelle session| Scénario | Utilisation |
| - | - |
| La session de l'utilisateur a été refusée pour un problème corrigeable (pièce d'identité floue, mauvais éclairage) | [Soumettre à nouveau](https://docs.didit.me/fr/console/manual-review.md) : même session, nouveau téléversement |
| Revérification complète ou re-KYC périodique | Créer une toute nouvelle session |
| Remédiation déclenchée par une règle de transaction | La transaction crée automatiquement une session de remédiation (statut `AWAITING_USER`) |## Exporter un rapport de conformitéPour les audits, les SAR ou les demandes des régulateurs, générez un PDF pour n'importe quelle session :```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
```Pour regrouper tout l'historique d'un utilisateur dans un seul fichier, téléchargez le [PDF d'historique utilisateur](https://docs.didit.me/fr/management-api/users/generate-pdf.md) : une page de garde (résumé du profil, statut des fonctionnalités, index des sessions), suivie du rapport complet de chaque session pouvant faire l'objet d'un rapport, de la plus ancienne à la plus récente, limité aux 20 sessions les plus récentes.```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
```Il s'agit du même document que celui produit par la console depuis *Users → \[user] → Actions → Download PDF*. Pour les exports CSV groupés sur plusieurs utilisateurs, utilisez l'export global dans *Review & Operations → Export PDF/CSV*.## Partager une session avec un tiersLorsque vous devez partager la vérification d'un utilisateur avec une application partenaire (par exemple dans un scénario de KYC réutilisable), utilisez :- `POST /v3/session/{session_id}/share/` pour générer un jeton partageable.
- `POST /v3/session/import-shared/` pour importer une session partagée côté destinataire.Consultez [KYC réutilisable](https://docs.didit.me/fr/core-technology/reusable-kyc/overview.md) pour le fonctionnement complet.## Workflows pilotés par l'historiqueUtilisez l'historique des sessions pour fonder des décisions de conformité plus pertinentes :- **Ignorer des étapes** si l'utilisateur dispose déjà d'une détection du vivant approuvée depuis moins de N jours.
- **Exiger des contrôles supplémentaires** si la session la plus récente de l'utilisateur a été refusée.
- **Signaler** lorsque le nombre de sessions d'un utilisateur augmente de façon inattendue.
- **Surveiller** les nouvelles réanalyses AML via la [surveillance AML continue](https://docs.didit.me/fr/core-technology/aml-screening/continuous-monitoring-aml-screening.md).## Étapes suivantes> [card] [Modèle de données](https://docs.didit.me/fr/entities/users/data-model.md)
>
> Comment les cartes de fonctionnalités et les compteurs sont calculés.> [card] [Récupérer une session](https://docs.didit.me/fr/sessions-api/retrieve-session.md)
>
> Schéma complet de la décision de session.> [card] [KYC réutilisable](https://docs.didit.me/fr/core-technology/reusable-kyc/overview.md)
>
> Réutiliser les données vérifiées entre applications.


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