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

# Mise à jour des données de session : corriger KYC et KYB

> Avec Didit, corrigez les champs KYC, justificatif de domicile ou KYB extraits par OCR. Trois endpoints PATCH, webhooks, facturation à l'appel.



Prompt de mise à jour des données de session
        Copier le prompt dans le presse-papiers



      
      

\<pre>

\`Correct OCR-extracted fields on a finished Didit verification session — KYC identity, Proof of Address, or KYB company data.

There are THREE separate PATCH endpoints. Pick the one that matches the feature record you need to fix.

1\) Update KYC identity data
PATCH https://verification.didit.me/v3/session/{session_id}/update-data/
\- Auth: x-api-key (client) or user-auth token. Privilege: write:sessions.
\- Session status must be one of Approved, Declined, In Review, Kyc Expired.
\- Session must have a captured KYC feature record.
\- Optional query / body param node_id targets a specific KYC instance in multi-step workflows (e.g. node_id=feature_ocr_2).
\- Mutable fields: document_type ("P", "ID", "DL", "RP"), document_number, personal_number, date_of_birth (ISO date), date_of_issue, expiration_date, issuing_state (ISO 3166-1 alpha-3), first_name, last_name (full_name is auto-recomputed), gender ("M"|"F"|"X"), nationality, marital_status, place_of_birth, address (free-text — triggers re-geocoding), parsed_address (nested: address_type, city, region, street_1, street_2, postal_code, country [ISO 3166-1 alpha-2]), extra_fields (object — send null on a key to remove it).

2\) Update Proof of Address (POA) data
PATCH https://verification.didit.me/v3/session/{session_id}/update-poa-data/
\- Same auth + privilege + status gate as KYC.
\- Session must have a captured POA record. node_id supported.
\- Mutable fields: issuing_state (ISO-3), document_type ("utility_bill" | "bank_statement" | "lease_agreement"), document_language (ISO 639-1), issuer, issue_date (ISO date), poa_address (free-text — triggers re-geocoding), name_on_document, poa_parsed_address (same nested shape as KYC parsed_address), extra_fields (bank_account_number, bank_iban, bank_sort_code, bank_routing_number, bank_swift_bic, bank_branch_name, bank_branch_address, document_phone_number, additional_names).

3\) Update KYB company data
PATCH https://verification.didit.me/v3/session/{session_id}/kyb/{company_uuid}/update-data/
\- Privilege: write:businesses (NOT write:sessions).
\- No status gate — KYB company data can be corrected at any time.
\- company_uuid must belong to that session_id (else 404).
\- Mutable fields: company_name, registration_number, country_code (ISO-3), incorporation_date / registration_date / dissolution_date, tax_number, legal_address (lands on registered_address), company_type, registry_status ("active" | "dissolved" | "struck_off" | "inactive" | ...), verification_status ("verified" | "failed" | "unknown"), alternative_names, nature_of_business, registered_capital, website, email, phone, legal_entity_identifier, location_of_registration, control_scheme.
\- Edits BOTH the canonical column and registry_data. user_provided_data is never touched.

4\) Skip (or re-require) a Key People party
PATCH https://verification.didit.me/v3/session/{session_id}/kyb/parties/{party_uuid}/
\- Privilege: write:businesses.
\- Body: { "is_skipped": true } to exempt the party, { "is_skipped": false } to put it back in scope.
\- party_uuid must belong to that session_id (else 404).
\- Use it when a party can no longer finish its own check - most often because the linked individual KYC session was deleted - and the KYB is stuck in Awaiting User with nothing left that can move it.
\- Independent of the role's allow_skip setting: that flag limits what the applicant may skip in the hosted flow, not what you may override.
\- requires_verification is left untouched, so the override stays visible as requires_verification: true + is_skipped: true.
\- Recomputes the Key People check and the parent session status immediately, and fires data.updated with trigger: "console_key_people_skip".

Common contract for all four:
\- PATCH semantics — only fields you send are updated. Omit a field to leave it as-is. Send null on an extra_fields key to remove it.
\- A successful update fires a data.updated webhook (with session_kind: "user" or "business"). KYB company updates carry trigger: "console_registry_edit".
\- The audit trail records changed fields, previous + new values, and (for user-auth) the actor email.

KYC curl example:
curl -X PATCH "https://verification.didit.me/v3/session/<SESSION_ID>/update-data/" \
-H "x-api-key: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"first_name": "John",
"last_name": "Doe",
"date_of_birth": "1990-01-01",
"issuing_state": "ESP",
"extra_fields": { "municipality": "Madrid" }
}'

Response: the updated record (KYC / POA / KYB company shape — same fields as in the session decision).

Failure modes:
\- 401 — missing or invalid credentials.
\- 403 — { "detail": "You do not have permission to perform this action." } — caller lacks write:sessions (KYC/POA) or write:businesses (KYB company).
\- 404 — { "detail": "Not found." } — session, node_id, or company_uuid not found; OR the session does not carry the feature record you are patching (no KYC / no POA / no matching company).
\- 400 — validation error: invalid country code, unknown parsed_address key, extra_fields not an object, etc. Returned as { "<field>": ["..."] }.

When NOT to use these endpoints:
\- To ask the user to retake the document → use PATCH /v3/session/{id}/update-status/ with new_status: "Resubmitted" (see /sessions-api/update-status).
\- To change entity-level data → use /v3/users/{vendor_data}/ or /v3/businesses/{vendor_data}/.
\- To edit Key People names / roles / ownership - no public API; that data is submitted through the hosted flow. Only the is_skipped flag is patchable (endpoint 4).

Side effects:
\- Changes to KYC name / DOB / nationality can re-trigger AML if AML was still running.
\- Changes to address / poa_address re-run geocoding asynchronously (failures swallowed — they never fail the update).

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\</pre>



      
      

Coller dans

Parfois, l'OCR lit mal une pièce d'identité, une facture de services publics ou une entrée de registre. Didit expose trois endpoints PATCH que vous pouvez appeler pour corriger les données extraites, sans avoir à relancer l'intégralité de la vérification.| Endpoint | Utiliser quand |
| - | - |
| [`PATCH /v3/session/{id}/update-data/`](#mettre-à-jour-les-données-d’identité-kyc) | Corriger les valeurs extraites d'un document d'identité sur une session de **Vérification des utilisateurs (KYC)** |
| [`PATCH /v3/session/{id}/update-poa-data/`](#mettre-à-jour-les-données-du-justificatif-de-domicile-poa) | Corriger les valeurs extraites d'une facture de services publics, d'un relevé bancaire ou d'un contrat de bail sur une session de **Vérification des utilisateurs (KYC)** |
| [`PATCH /v3/session/{id}/kyb/{company_uuid}/update-data/`](#mettre-à-jour-les-données-de-l’entreprise-kyb) | Corriger les champs extraits du registre sur une session de **Vérification d'entreprise (KYB)** |
| [`PATCH /v3/session/{id}/kyb/parties/{party_uuid}/`](#ignorer-une-partie-des-personnes-clés) | Exempter une partie « personnes clés » de la vérification lorsqu'elle ne peut plus effectuer son propre contrôle |Les quatre acceptent votre clé API client ou un en-tête d'autorisation utilisateur, et les quatre émettent un événement webhook `data.updated` en cas de réussite, afin que votre système et vos analyses en aval restent synchronisés.## Exigences communes- **Autorisation** : clé API client (`x-api-key` / `Authorization` bearer standard) ou token d'autorisation utilisateur.
- **Privilège** :
  * KYC et POA : `write:sessions`
  * Entreprise KYB et partie « personnes clés » : `write:businesses`
- **Statut de la session** (KYC / POA uniquement) : doit être l'un de `APPROVED`, `DECLINED`, `IN_REVIEW` ou `KYC_EXPIRED`. Les sessions qui n'ont pas atteint un état pouvant faire l'objet d'un examen ne peuvent pas être corrigées. Les mises à jour de l'entreprise KYB ne sont soumises à aucune condition de statut.
- **L'enregistrement de la fonctionnalité doit exister** : vous ne pouvez corriger les champs KYC que si la session a capturé un KYC, les champs POA si elle a capturé un POA, et les champs de l'entreprise KYB si la session comporte une vérification de registre.
- **Mises à jour partielles** : seuls les champs que vous incluez sont modifiés. Omettez un champ pour le laisser inchangé. Envoyez `null` pour supprimer une clé de `extra_fields`.
- **Webhooks** : une mise à jour réussie déclenche `data.updated` avec `session_kind: "user"` ou `"business"`, et le journal d'audit de la session enregistre les champs précis modifiés ainsi que la personne qui les a modifiés.## Mettre à jour les données d'identité KYC**`PATCH /v3/session/{sessionId}/update-data/`**Corrigez n'importe quel champ extrait du document d'identité. Prend en charge les workflows multi-instances basés sur un graphe, via le paramètre de requête facultatif `node_id` ou un champ du corps de la requête : ciblez un enregistrement KYC précis lorsqu'une même session comporte plusieurs étapes KYC.### Champs modifiables| Champ | Remarques |
| - | - |
| `document_type` | Code ISO du document : `P` (passeport), `ID`, `DL`, `RP`. |
| `document_number` | Le numéro de document imprimé. |
| `personal_number` | Numéro personnel ou identifiant fiscal, lorsqu'il figure sur le document. |
| `date_of_birth` | Date ISO 8601. |
| `date_of_issue` / `expiration_date` | Dates ISO 8601. |
| `issuing_state` | Pays de délivrance, ISO 3166-1 alpha-3. |
| `first_name` / `last_name` | `full_name` est recalculé automatiquement à partir de ces deux champs. |
| `gender` | `M`, `F` ou `X`, le cas échéant. |
| `nationality` | Texte libre. |
| `marital_status` | Texte libre. |
| `place_of_birth` | Texte libre. |
| `address` | Adresse en texte libre, telle qu'elle figure sur le document. Déclenche un nouveau géocodage. |
| `parsed_address` | Adresse structurée : voir la forme imbriquée ci-dessous. |
| `extra_fields` | Champs supplémentaires quelconques issus de la pièce d'identité (par ex. `blood_group`, `municipality`). Envoyez `null` pour une clé afin de la supprimer. |`parsed_address` n'accepte que ces clés imbriquées : `address_type`, `city`, `region`, `street_1`, `street_2`, `postal_code`, `country` (ISO 3166-1 **alpha-2**).### Exemple```bash theme={null}
curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1990-01-01",
    "issuing_state": "ESP",
    "extra_fields": { "municipality": "Madrid" }
  }'
```Pour un workflow multi-instances basé sur un graphe, ajoutez `?node_id=feature_ocr_2` à l'URL (ou passez `"node_id": "feature_ocr_2"` dans le corps de la requête) pour cibler un enregistrement KYC précis.## Mettre à jour les données du justificatif de domicile (POA)**`PATCH /v3/session/{sessionId}/update-poa-data/`**Corrigez les champs extraits d'un justificatif de domicile. Mêmes conditions de statut et même privilège que pour les mises à jour KYC. Prend également en charge `node_id` pour les workflows multi-instances.### Champs modifiables| Champ | Remarques |
| - | - |
| `issuing_state` | Pays ayant émis le document, ISO 3166-1 alpha-3. |
| `document_type` | Par ex. `utility_bill`, `bank_statement`, `lease_agreement`. |
| `document_language` | Langue du document, ISO 639-1. |
| `issuer` | Fournisseur de services publics, banque, bailleur, etc. |
| `issue_date` | Date ISO 8601. |
| `poa_address` | Adresse telle qu'elle est imprimée sur le document (texte libre). Déclenche un nouveau géocodage. |
| `name_on_document` | Nom complet imprimé sur le document. |
| `poa_parsed_address` | Adresse structurée : même forme imbriquée que le `parsed_address` KYC. |
| `extra_fields` | Champs propres au document : coordonnées bancaires (`bank_account_number`, `bank_iban`, `bank_sort_code`, `bank_routing_number`, `bank_swift_bic`, `bank_branch_name`, `bank_branch_address`), `document_phone_number`, `additional_names` (liste ou `null`). |### Exemple```bash theme={null}
curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-poa-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "utility_bill",
    "issuer": "Iberdrola",
    "issue_date": "2026-03-15",
    "name_on_document": "Jane Doe",
    "poa_parsed_address": {
      "street_1": "Calle Mayor 10",
      "city": "Madrid",
      "postal_code": "28013",
      "country": "ES"
    }
  }'
```## Mettre à jour les données de l'entreprise KYB**`PATCH /v3/session/{sessionId}/kyb/{companyUuid}/update-data/`**Corrigez les champs extraits du registre pour une entreprise KYB. L'endpoint modifie **à la fois** les colonnes canoniques de l'entreprise et `registry_data`, afin que la vue « Extracted from Registry » de la console reflète vos corrections. `user_provided_data` (ce que l'utilisateur final a confirmé dans le parcours hébergé) n'est pas modifié. `last_console_edit_at` est horodaté et un webhook `data.updated` est déclenché avec `trigger: "console_registry_edit"`.### Prérequis- **Privilège** : `write:businesses` (différent du privilège KYC / POA).
- Le `companyUuid` présent dans l'URL doit appartenir au `sessionId` indiqué, sinon vous obtenez une erreur 404.
- Aucune restriction liée au statut de la session : les données de l'entreprise KYB peuvent être corrigées à tout moment.### Champs modifiables| Champ | Remarques |
| - | - |
| `company_name` | Raison sociale légale. |
| `registration_number` | Numéro d'immatriculation officiel. |
| `country_code` | Pays de constitution, ISO 3166-1 alpha-3. |
| `incorporation_date` / `registration_date` / `dissolution_date` | Dates au format ISO 8601. |
| `tax_number` | Identifiant fiscal. |
| `legal_address` | Alias de `registered_address` : la valeur est écrite dans la colonne canonique `registered_address`. |
| `company_type` | Ltd / LLC / PLC / SA / GmbH / SL, etc. |
| `registry_status` | `active`, `dissolved`, `struck_off`, `inactive`, etc. |
| `verification_status` | `verified`, `failed`, `unknown`. |
| `alternative_names` | Noms commerciaux, anciens noms, DBA. |
| `nature_of_business` | Brève description. |
| `registered_capital` | Capital autorisé / émis. |
| `website`, `email`, `phone` | Coordonnées. |
| `legal_entity_identifier` | LEI. |
| `location_of_registration` | Ville / subdivision. |
| `control_scheme` | Mode de gouvernance, lorsque le registre le fournit. |Tout champ omis reste inchangé. Tout champ envoyé est écrit dans la colonne canonique (lorsqu'elle existe) et fusionné dans `registry_data`. Les dates sont sérialisées en chaînes ISO 8601 lors de la fusion dans `registry_data`.### Exemple```bash theme={null}
curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/f7a9c1b2-4e6d.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_name": "Acme Corporation Limited",
    "registration_number": "12345678",
    "registry_status": "active",
    "legal_address": "1 Main Street, London EC1A 1AA, United Kingdom",
    "alternative_names": "Acme Ltd, Acme Group"
  }'
```Réponse : l'objet complet de l'entreprise KYB, de même structure que `registry_checks[].company` dans la [décision de session](https://docs.didit.me/fr/sessions-api/retrieve-session.md#vérification-d’entreprise-kyb).## Ignorer une partie des personnes clés**`PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/`**Exemptez une partie des personnes clés de la vérification : c'est la solution de repli pour une partie qui ne pourra jamais terminer sa propre vérification. La cause habituelle est la suppression d'une session enfant : une fois que la vérification KYC individuelle attribuée à un UBO ou à un dirigeant est supprimée, son statut est figé et ne peut plus aboutir. La KYB ne dispose alors d'aucun moyen de la faire sortir de `Awaiting User`. Ignorer la partie la retire de l'agrégation des personnes clés, la vérification est recalculée immédiatement, et la session peut alors aboutir et être approuvée ou refusée.### Prérequis- **Privilège** : `write:businesses`.
- Le `partyUuid` présent dans l'URL doit appartenir au `sessionId` indiqué, sinon vous obtenez une erreur 404.
- **Non soumis à `allow_skip`.** Ce paramètre de rôle limite ce que le demandeur peut ignorer lorsqu'il remplit l'écran hébergé des personnes clés. Cet endpoint est la dérogation de l'opérateur : il fonctionne donc même pour les rôles que le demandeur n'aurait pas pu ignorer.### Corps de la requête| Champ | Type | Remarques |
| - | - | - |
| `is_skipped` | booléen | `true` exclut la partie ; `false` la réintègre dans le périmètre et la vérification revient à attendre cette partie. |`requires_verification` n'est volontairement pas modifié : une partie ainsi dérogée apparaît donc avec `requires_verification: true` **et** `is_skipped: true`. L'enregistrement indique toujours que les règles exigeaient une vérification.### Exemple```bash theme={null}
curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/parties/0a3f1e2c-7c2f.../" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "is_skipped": true }'
```Réponse : la partie mise à jour, de même structure qu'une entrée de `key_people_checks[].submitted.parties[]` dans la [décision de session](https://docs.didit.me/fr/business-verification/response-schema.md#key_people_checks).Un webhook `data.updated` est déclenché avec `trigger: "console_key_people_skip"`.> [!NOTE]
>
> Une partie dont la session enfant a été supprimée est signalée dans la charge utile de la décision avec
> `kyc_session_deleted: true` (ou `kyb_sub_session_deleted: true` pour les parties d'entreprises), et son
> `kyc_session_url` / `kyb_sub_session_url` est renvoyée avec la valeur `null`, car le lien ne mène plus nulle part.
> La suppression d'une session enfant n'approuve jamais la partie à elle seule : la vérification des personnes clés passe à
> `In Review`, afin qu'une personne tranche.## Ce qui se passe après une mise à jour- **Webhook** : `data.updated` est déclenché pour la session, avec son `session_kind` dans le payload (`"user"` ou `"business"`). Abonnez-vous une fois au niveau de la destination de webhook et aiguillez selon `session_kind`.
- **Piste d'audit** : la session enregistre précisément les champs modifiés, les anciennes et nouvelles valeurs et, pour les appels authentifiés par utilisateur, l'e-mail de l'acteur. Visible dans l'onglet Events de la console.
- **Nouveau géocodage de l'adresse** : pour les mises à jour KYC et POA qui modifient `address` / `poa_address`, Didit relance le géocodage en arrière-plan. Les échecs sont ignorés afin que la mise à jour n'échoue jamais en raison d'un problème de géocodage.
- **Réévaluation AML** : les mises à jour KYC qui modifient le nom, la date de naissance ou la nationalité peuvent relancer le filtrage AML si celui-ci n'était pas terminé pour la session. Les résultats apparaissent dans la décision de session.## Quand ne pas utiliser ces endpoints- **Relancer la vérification complète** : si le client doit reprendre la photo de sa pièce d'identité ou téléverser à nouveau un document, utilisez plutôt [update-status](https://docs.didit.me/fr/sessions-api/update-status.md) pour faire passer la session à `Resubmitted`.
- **Modifier les champs de profil de l'entité User ou Business** : utilisez [`PATCH /v3/users/{vendor_data}/`](https://docs.didit.me/fr/management-api/users/update) ou [`PATCH /v3/businesses/{vendor_data}/`](https://docs.didit.me/fr/management-api/businesses/update). Ces endpoints mettent à jour les données au niveau de l'entité, et non au niveau de la session.
- **Modifier les détails des personnes clés** : aucune API publique ne permet de modifier le nom, les rôles ou l'actionnariat d'une partie. Ces données sont soumises via le parcours hébergé. Le seul champ modifiable est `is_skipped` (voir [Ignorer une partie des personnes clés](#ignorer-une-partie-des-personnes-clés)).## Erreurs| Statut | Signification |
| - | - |
| `401` | Identifiants absents ou invalides. |
| `403` | L'appelant ne dispose pas du droit requis (`write:sessions` ou `write:businesses`). |
| `404` | Session introuvable, ou la session ne contient pas l'enregistrement que vous tentez de modifier (aucun KYC, aucune POA, aucune entreprise correspondante, aucune partie correspondante, ou une partie qui appartient à une autre session). |
| `400` | Erreur de validation : code pays invalide, clé `parsed_address` inconnue, `extra_fields` qui n'est pas un objet, etc. |## Étapes suivantes> [card] [Récupérer la session](https://docs.didit.me/fr/sessions-api/retrieve-session.md)
>
> Récupérez la décision complète pour voir les champs mis à jour.> [card] [Mettre à jour le statut](https://docs.didit.me/fr/sessions-api/update-status.md)
>
> Approuvez, refusez ou rouvrez une session après une correction des données.> [card] [Webhooks](https://docs.didit.me/fr/integration/webhooks.md)
>
> Abonnez-vous aux événements `data.updated`.


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