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

# Exemples MCP Didit : prompts et conversations d'agents

> Exemples de prompts et de conversations d'agents avec le MCP Didit : workflow KYC et session, recherche KYB, file de revue, back-test de règles, webhook.

Quelques exemples de ce que le MCP Didit fait bien. Formulez vos demandes en langage courant : l'agent choisit les outils. Chaque outil mentionné ci-dessous figure dans la [référence des outils](https://docs.didit.me/fr/integration/mcp/tools.md).

***

## Exemples de demandes rapides

**Opérations et surveillance (toutes applications)**

* *« Affiche-moi les 5 dernières sessions en cours d'examen, toutes applications confondues. »* → `didit_session_search` avec `status: "In Review"`, `limit: 5`
* *« Combien de personnes ont commencé la vérification du téléphone sans la terminer au cours des 15 derniers jours ? »* → `didit_analytics` avec `last_n_days: 15` (un seul appel ; lit l'entonnoir des fonctionnalités)
* *« Trouve le client dont le vendor\_data est `user_8842` et indique-moi son application et son statut. »* → `didit_vendor_user_search`
* *« Quel est mon solde de crédits et quel est le taux de conversion de ce mois-ci ? »* → `didit_org_get_balance` + `didit_analytics`

**Configuration**

* *« Crée un workflow KYC avec scan de pièce d'identité et détection du vivant, puis donne-moi un lien de vérification. »* → `didit_workflow_create` → `didit_session_create`
* *« Crée un workflow de vérification d'identité qui n'accepte que les passeports, suivi d'une détection du vivant par selfie. »* → `didit_workflow_create` : indique simplement `documents_allowed: ["PASSPORT"]` ; le MCP l'étend pour n'autoriser que les passeports dans chaque pays (voir [Avancé → configurations des fonctionnalités](https://docs.didit.me/fr/integration/mcp/advanced.md#configurations-des-fonctionnalités-et-listes-d’autorisation)).
* *« Nouveau workflow : scanner un passeport ; si la pièce d'identité est refusée, refuser la session ; si la profession déclarée est ≈ « Software Engineer » (≥60%), lancer une détection du vivant ; sinon, demander un justificatif de domicile en espagnol ; puis décider automatiquement. »* → `didit_workflow_get_field_definitions` → `didit_workflow_validate_graph` → `didit_workflow_set_graph`
* *« Dans le workflow `26d33c04…`, après la vérification d'identité : si elle est refusée, refuser la session ; si la profession présente une similarité d'au moins 80 % avec « Software Engineer », ajouter une étape Document AI de justificatif de fonds ; puis continuer. »* → `didit_workflow_search` → `didit_workflow_get_graph` → `didit_workflow_edit_graph` (petites modifications, enregistrées comme brouillon à examiner)
* *« Dans quels pays puis-je proposer une connexion BankID ou MitID à la place d'un scan de document ? »* → `didit_workflow_get_id_verification_methods_catalog`
* *« Enregistre une destination de webhook pour les mises à jour de statut sur `https://myapp.com/webhooks/didit`. »* → `didit_webhook_create`

**Conformité**

* *« Soumets ce portefeuille au filtrage AML et ajoute-le à la liste de blocage en cas de correspondance. »* → `didit_transaction_screen_wallet` → `didit_blocklist_add`
* *« Ouvre un dossier pour la session `…` et assigne-le-moi. »* → `didit_case_create` → `didit_case_manage`
* *« Acme Ltd est-elle une société immatriculée au Royaume-Uni, et qui sont ses actionnaires ? »* → `didit_verify_kyb_search` → `didit_verify_kyb_select`

***

## 1. Mettre en place la vérification

> **Vous :** « Configure la vérification d'identité Didit pour mon application avec scan de pièce d'identité et détection du vivant, et donne-moi un lien pour que je puisse l'essayer. »
>
> **Agent :** Je commence par créer le workflow. *(appelle `didit_workflow_create` avec `workflow_label: "Standard KYC"`, `features: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]`)* — Le workflow **« Standard KYC »** est publié, `workflow_id = 6f2c…`. Je crée maintenant une session pour le tester. *(appelle `didit_session_create` avec `workflow_id: "6f2c…"`, `vendor_data: "test-user-1"`)* — Voici votre lien : `https://verify.didit.me/session/…`. Ouvrez-le sur votre téléphone pour parcourir le flux. En production, votre backend crée les sessions avec l'API REST :
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
>   -H "x-api-key: $DIDIT_API_KEY" \
>   -H "Content-Type: application/json" \
>   -d '{ "workflow_id": "6f2c...", "vendor_data": "internal-user-id", "callback": "https://myapp.com/done" }'
> ```
>
> Cet `x-api-key` est la **clé API REST** de votre application, destinée à votre backend ; elle est distincte de la façon dont vous vous êtes connecté à ce MCP, qui utilise *Log in with Didit*. Voulez-vous que j'enregistre aussi la destination du webhook ?
>
> **Vous :** « Oui, mon endpoint est `https://myapp.com/webhooks/didit`. »
>
> **Agent :** *(appelle `didit_webhook_create` avec `label: "Production"`, `url: "https://myapp.com/webhooks/didit"`, `webhook_version: "v3"`, `subscribed_events: ["status.updated"]`)* — C'est fait. Le secret de signature est masqué dans la réponse ; copiez-le depuis **Webhooks** dans la console et enregistrez-le comme `DIDIT_WEBHOOK_SECRET`. Vérifiez l'en-tête `X-Signature-V2` de chaque livraison avant de lui faire confiance.

***

## 2. KYB : vérifier une entreprise dans le registre

> **Vous :** « Acme Trading Ltd est-elle une véritable société britannique ? Son numéro d'immatriculation est 12345678. »
>
> **Agent :** *(appelle `didit_verify_kyb_search` avec `country_code: "GB"`, `name: "Acme Trading Ltd"`, `registration_number: "12345678"`)* — Un résultat : **ACME TRADING LTD**, constituée en 2019, statut *actif*, siège social à Manchester. Voulez-vous la fiche complète, avec les dirigeants et les actionnaires ?
>
> **Vous :** « Oui, et dis-moi qui sont les bénéficiaires effectifs. »
>
> **Agent :** *(appelle `didit_verify_kyb_select` avec le `kyb_response_id` du résultat)* — Fiche complète récupérée : deux dirigeants, et une personne exerçant un contrôle significatif, détenant 75%+ des actions et des droits de vote. La fiche comprend l'historique des dépôts et l'adresse du siège. Cette consultation du registre est facturable (deux appels consommant des crédits). Si vous voulez que cela se fasse automatiquement pour chaque entreprise cliente, je peux ajouter `KYB_REGISTRY` à un workflow KYB avec `didit_workflow_create` ; `didit_workflow_get_kyb_registry_catalog` indique quels niveaux de données le registre britannique vend.

***

## 3. Traiter la file d'attente d'examen

> **Vous :** « Qu'est-ce qui attend mon examen, et quel est le problème pour chaque cas ? »
>
> **Agent :** *(appelle `didit_session_search` avec `status: "In Review"`, `limit: 10`)* Quatre sessions réparties sur deux applications sont en cours d'examen. Je lis la décision de chacune. *(appelle `didit_session_get_decision` pour chaque `session_id`)*
>
> | Session | Application | Motif du blocage |
> | - | - | - |
> | `a1f3…` | Onboarding | Score de correspondance faciale 71 (seuil 80), détection du vivant réussie |
> | `b7c2…` | Onboarding | Document expiré depuis 2 mois |
> | `c904…` | Marketplace | AML : une correspondance PEP, correspondance du nom à 92%, date de naissance différente |
> | `d215…` | Marketplace | Justificatif de domicile daté de plus de 90 jours |
>
> **Vous :** « Approuvez `a1f3` : j'ai regardé le selfie, c'est la même personne. Refusez `b7c2`, document expiré. »
>
> **Agent :** *(appelle `didit_session_update_status` avec `session_id: "a1f3…"`, `new_status: "Approved"`, puis avec `session_id: "b7c2…"`, `new_status: "Declined"`, `comment: "Expired document"`)* Les deux sessions ont été mises à jour. *(appelle `didit_session_add_review` sur `a1f3…` avec la note « Examen manuel du selfie : même personne »)* Note de revue ajoutée afin que le journal d'audit indique pourquoi le score a été modifié manuellement. Les deux dossiers, celui d'AML et celui de justificatif de domicile, restent ouverts ; dites-le-moi et j'ouvrirai un dossier pour la correspondance PEP avec `didit_case_create`.

***

## 4. Tester rétroactivement une règle de transaction avant sa mise en production

> **Vous :** « Je veux signaler toute personne qui effectue plus de 3 virements supérieurs à \$1,000 en une heure. Combien d'alertes cela générerait-il ? »
>
> **Agent :** *(appelle `didit_transaction_rule_backtest` avec `conditions` sur `amount > 1000`, une `aggregation` de count ≥ 3 sur une fenêtre de 1 heure, `period_days: 90`)* Sur les 90 derniers jours, cette règle se serait déclenchée sur 14 transactions provenant de 6 sujets ; 2 de ces sujets sont déjà signalés. Voulez-vous que je la crée en mode `TEST`, afin qu'elle enregistre les correspondances sans exécuter aucune action ?
>
> **Vous :** « Oui, mode TEST. »
>
> **Agent :** *(appelle `didit_transaction_rule_create` avec `title: "Velocity: 3+ transfers over $1,000 per hour"`, `category: "aml_ctf"`, `mode: "TEST"`, les mêmes `conditions` et `aggregation`, et une liste `actions` qui signale le sujet)* Créée. Suivez-la avec `didit_transaction_rule_get` après quelques jours ; lorsque vous êtes satisfait, `didit_transaction_rule_update` fait passer `mode` à `ACTIVE`. `didit_transaction_rule_library_list` contient aussi les règles de vélocité prédéfinies de Didit si vous préférez en installer une.

***

## Les résultats de session sont asynchrones

`didit_session_create` renvoie un `session_id`, un `session_token` et une `url` hébergée, mais la vérification n'a pas encore eu lieu. L'utilisateur ouvre `url` et termine le parcours. La décision finale est transmise de l'une des façons suivantes :

1. Un **webhook** `status.updated` (recommandé), ou
2. `didit_session_get_decision` (interrogation, en solution de repli).

Les deux ont la même structure : **toujours des tableaux au pluriel** avec un `node_id` par entrée :

```json theme={null}
{
  "session_id": "uuid",
  "status": "Approved",
  "session_kind": "user",
  "id_verifications":  [ { "node_id": "first_id", "status": "Approved", "first_name": "Jane" } ],
  "liveness_checks":   [ { "node_id": "first_liveness", "status": "Approved", "score": 95.4 } ],
  "face_matches":      [ { "node_id": "first_face_match", "status": "Approved", "score": 96.1 } ],
  "aml_screenings":    [ { "node_id": "first_aml", "status": "Approved", "total_hits": 0, "hits": [] } ],
  "reviews": []
}
```

Ne lisez jamais les clés V2 au singulier (`id_verification`, `liveness`) : elles ne sont envoyées que lorsqu'une destination est explicitement fixée à `webhook_version: "V2"`. Consultez [Modèles de données](https://docs.didit.me/fr/reference/data-models.md) pour la référence des champs par fonctionnalité, et [Avancé → Webhooks](https://docs.didit.me/fr/integration/mcp/advanced.md#gestion-des-webhooks) pour les règles de vérification et de nouvelle tentative.

***

## Associer MCP à l'intégration en un seul prompt

Le MCP est idéal pour *faire fonctionner* Didit. Pour qu'un agent *écrive* une intégration complète (route backend + SDK frontend + gestionnaire de webhook + schéma de base de données), donnez-lui le [prompt d'intégration](https://docs.didit.me/fr/integration/integration-prompt.md) : il suit les sept étapes et appelle les outils MCP pour créer en direct le workflow, la session et le webhook.

***

> [card] [Référence des outils](https://docs.didit.me/fr/integration/mcp/tools.md)
>
> Tout ce que l'agent peut appeler.

> [card] [Fonctionnalités avancées et dépannage](https://docs.didit.me/fr/integration/mcp/advanced.md)
>
> Rôles, comportement inter-applications, webhooks, auto-hébergement.


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