> ## 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. # Importer des vérifications depuis un autre fournisseur > Didit : choisissez le bon import pour vos sessions, utilisateurs, visages, listes de blocage, entreprises, transactions et règles de statut. Utilisez ce guide pour choisir la bonne méthode d'importation lorsque vous migrez des données d'un autre fournisseur vers Didit. Les clients appellent souvent « import » deux opérations différentes :- **Importer des vérifications historiques** : recréez des contrôles KYC et KYB, des enregistrements de surveillance des transactions ou des règles de workflow déjà terminés, afin que Didit affiche l'historique de l'ancien fournisseur. Utilisez `POST /v3/session/imports/`. - **Importer des données opérationnelles** : créez des Utilisateurs, des Entreprises, des visages de profil, des entrées de liste de blocage ou d'autorisation, afin que Didit puisse les utiliser lors de futures vérifications. Utilisez les API des entités, des visages et des listes.Les imports de vérification créent des enregistrements historiques avec `session_type: "MIGRATED"` pour le KYC et le KYB. Ils n'envoient aucun e-mail à l'utilisateur final, ne redirigent pas les utilisateurs vers le parcours hébergé et ne relancent pas la vérification d'origine. Les enregistrements importés apparaissent dans les listes de sessions, les profils d'entités, les vues des transactions et `GET /v3/session/{session_id}/decision/` lorsque c'est applicable.## Quel import utiliser ?| Objectif | Méthode d'importation à utiliser | Ce qu'elle crée | Idéal pour | | - | - | - | - | | Recréer des sessions KYC historiques | `POST /v3/session/imports/` avec `import_type=user_verification` | `Session`, données de Vérification d'identité, images de document ou de selfie facultatives, vidéos de document et de détection du vivant, tags, métadonnées | Migrer des candidats ayant terminé leur vérification depuis Sumsub, MetaMap, Veriff, Onfido, Persona, Jumio, Incode, iDenfy, Trulioo ou un autre fournisseur KYC | | Recréer des sessions KYB historiques | `POST /v3/session/imports/` avec `import_type=business_verification` | `BusinessSession`, données d'entreprise issues du registre, dirigeants, bénéficiaires effectifs, tags, métadonnées | Migrer des contrôles KYB terminés depuis des fournisseurs KYB, des fournisseurs de registres des sociétés ou des outils KYB internes | | Recréer des enregistrements historiques de surveillance des transactions | `POST /v3/session/imports/` avec `import_type=transactions` | `Transaction`, parties sujet et contrepartie, résultats des fournisseurs, données Travel Rule, instantané du réseau, métadonnées | Migrer l'historique de la surveillance des transactions par moteur de règles, du KYT, du filtrage des portefeuilles ou de la surveillance des transactions fiat | | Importer des règles de statut de workflow personnalisées | `POST /v3/session/imports/` avec `import_type=status_rules` | `VerificationSettings.feature_status_rules` | Migrer la logique de politique d'un autre fournisseur ou d'un tableur vers le moteur de workflow de Didit | | Créer des Utilisateurs sans sessions historiques | `POST /v3/users/create/` ou import CSV depuis la Console | Lignes de profil `VendorUser` | Charger votre liste d'utilisateurs avant de lancer de nouvelles vérifications Didit | | Associer des visages de profil de confiance aux utilisateurs | `POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/` | Preuves de visage de profil indexées pour la détection de doublons et la Recherche faciale | Migrer des images de visage de profil depuis un autre fournisseur KYC sans recréer les sessions complètes | | Mettre sur liste de blocage ou d'autorisation des visages | `POST /v3/lists/{list_uuid}/entries/face-upload/` ou `POST /v3/lists/{list_uuid}/entries/` avec `reference_session_id` | Entrée de liste de visages et embedding biométrique | Migrer des visages de fraudeurs connus, des visages de la liste d'autorisation de confiance, ou mettre sur liste de blocage le visage d'une session Didit existante | | Créer des Entreprises sans sessions KYB historiques | `POST /v3/businesses/create/` ou import CSV depuis la Console | Lignes de profil `VendorBusiness` | Charger votre liste de clients entreprises avant de lancer un KYB |> [!NOTE] > > Si vous n'avez besoin que d'un profil d'utilisateur ou d'entreprise pour de futures vérifications, n'importez pas de session de vérification historique. Utilisez les API des entités Utilisateur ou Entreprise. Si vous souhaitez que la décision, les champs de document, les avertissements ou les preuves de l'ancien fournisseur apparaissent dans Didit comme historique de conformité, utilisez `POST /v3/session/imports/`.## Ce qui peut être migré depuis chaque fournisseurDidit accepte un fichier CSV ou NDJSON canonique : vous pouvez donc migrer depuis n'importe quel fournisseur, une fois les données exportées et transformées. Le contrat d'import est toujours le schéma canonique de Didit.| Famille de fournisseurs | Sources habituelles | Généralement migrable | Remarques | | - | - | - | - | | Fournisseurs KYC | Sumsub, MetaMap, Veriff, Onfido, Persona, Jumio, Incode, iDenfy, Trulioo, HyperVerge, AU10TIX, Mitek, Ondato | Identifiant du demandeur, identifiant utilisateur chez le fournisseur, statut de décision, champs de document, images de document, image de selfie ou image de vivacité, libellés de rejet, étiquettes, métadonnées brutes du fournisseur | Utilisez `import_type=user_verification`. Si le fournisseur ne peut pas exporter les images, importez les champs structurés et laissez vides les URL des images. | | Fournisseurs KYB | Fournisseurs de registres d'entreprises, Sumsub KYB, Trulioo KYB, exports de registres de type Creditsafe, outils KYB internes | Nom de l'entreprise, numéro d'immatriculation, pays, statut au registre, dirigeants, bénéficiaires effectifs, niveau de risque, payload brut du registre | Utilisez `import_type=business_verification`. Les dirigeants et les UBO sont transmis sous forme de tableaux JSON. | | Fournisseurs de surveillance des transactions / KYT | Sumsub Transaction Monitoring, exports KYT de type Chainalysis, Crystal, Merkle Science, Sardine, Unit21, Alloy, moteurs de règles internes | Identifiant de transaction, montant, devise, sens, entité/contrepartie, règles déclenchées, résultats du fournisseur, statut Travel Rule, instantané du graphe de réseau | Utilisez `import_type=transactions`. Les transactions importées sont des enregistrements historiques ; elles ne font pas l'objet d'un nouveau filtrage par défaut. | | Tableurs de workflows et de politiques | Exports de politiques de conformité, tables de règles des fournisseurs, tableurs de risque internes | Règles de statut par fonctionnalité, par exemple « si le pays de délivrance est X, définir Vérification d'identité sur en cours d'examen » | Utilisez `import_type=status_rules`. Les règles sont validées par rapport au catalogue des champs de workflow de Didit avant d'être enregistrées. | | Bases d'utilisateurs et de profils | CRM, base de données clients, export des utilisateurs du fournisseur, entrepôt de données | `vendor_data`, nom d'affichage, métadonnées, étiquettes, images de visage de confiance | Utilisez les API utilisateurs et le téléversement d'une image de visage de profil. Il ne s'agit pas d'une session de vérification terminée. | | Données de listes de blocage et d'autorisation | Listes de fraude des fournisseurs, feuilles de suivi de la fraude internes, listes de rétrofacturation, listes internes proches des sanctions | E-mails, téléphones, documents, portefeuilles, adresses IP, empreintes d'appareil, visages, pays, utilisateurs, entreprises | Utilisez les API de listes. Pour les images de visage, utilisez l'endpoint d'envoi de visage dédié afin que Didit puisse extraire l'embedding facial. |## Flux de migration1) Décidez si vous importez l'historique, les profils, les visages, les listes, les transactions ou les règles. 2) Exportez vous-même les données de l'ancien fournisseur. N'envoyez pas les clés API de l'ancien fournisseur à Didit. 3) Transformez l'export du fournisseur en modèle CSV ou NDJSON canonique de Didit correspondant. 4) Pour les migrations volumineuses, privilégiez NDJSON et découpez les données en fichiers que vous pouvez réessayer indépendamment. 5) Créez la tâche d'import, puis suivez sa progression en interrogeant régulièrement son état. 6) Récupérez les erreurs de lignes, corrigez uniquement les lignes en échec et réessayez-les. Toutes les tâches d'import sont idempotentes sur leur identifiant externe naturel.## Créer une tâche d'importCréez une tâche d'import avec une seule requête multipart :```bash theme={null} curl -X POST https://verification.didit.me/v3/session/imports/ \ -H "x-api-key: YOUR_API_KEY" \ -F "import_type=user_verification" \ -F "workflow_id=YOUR_KYC_WORKFLOW_ID" \ -F "file=@didit-import.ndjson" ```Utilisez CSV pour les migrations plus petites pilotées par tableur et NDJSON pour les migrations volumineuses. Pour 100k+ lignes, NDJSON est plus facile à diffuser en flux, découper, valider et réessayer.Une application peut exécuter jusqu'à 4 tâches d'import simultanément : découpez donc une migration volumineuse en plusieurs fichiers et lancez une tâche par fichier. Chaque tâche télécharge en parallèle les fichiers médias d'une ligne. Une tâche interrompue par un déploiement ou le redémarrage d'un processus de travail reprend d'elle-même à partir de sa dernière ligne importée ; vous n'avez donc pas besoin de la relancer.Pour les imports de transactions, omettez `workflow_id` :```bash theme={null} curl -X POST https://verification.didit.me/v3/session/imports/ \ -H "x-api-key: YOUR_API_KEY" \ -F "import_type=transactions" \ -F "file=@didit-transactions.ndjson" ```### Champs de la requête| Champ | Obligatoire | Description | | - | - | - | | `import_type` | Non, valeur par défaut `user_verification` | L'une de : `user_verification`, `business_verification`, `status_rules`, `transactions`. | | `workflow_id` | Oui, sauf pour `transactions` | UUID du workflow auquel les enregistrements importés sont rattachés. `user_verification` et `status_rules` nécessitent un workflow de Vérification des utilisateurs ; `business_verification` nécessite un workflow de Vérification d'entreprise (KYB). | | `file` | L'un de `file` ou `source_file_url` | Le fichier CSV ou NDJSON canonique, envoyé directement dans la requête. | | `source_file_url` | L'un de `file` ou `source_file_url` | URL HTTPS à partir de laquelle Didit télécharge le fichier. Les URL de réseau privé sont rejetées. | | `source_format` | Non | `csv` ou `ndjson`. Déduit de l'extension du fichier lorsqu'il est omis. |### Comment les enregistrements sont suivis et dédupliquésIl n'existe aucun champ de requête pour la source des données : chaque import utilise le schéma canonique de Didit. Chaque enregistrement importé stocke `metadata.imported_from = "generic"` à des fins de traçabilité.Les imports `user_verification` et `business_verification` dédupliquent les lignes sur `external_id` au sein de l'application ; réessayer le même fichier ne crée donc pas de doublons. Les imports `transactions` dédupliquent plutôt sur `transaction_id`.Une migration depuis un fournisseur (`source=provider`) stocke chaque enregistrement sous la forme `:`, par exemple `sumsub:5f8c0e2a9b1d4c3e2f1a0b9c`. Un import de fichier de Vérification des utilisateurs qui envoie l'identifiant brut du fournisseur (`5f8c0e2a9b1d4c3e2f1a0b9c`) est reconnu comme le même enregistrement, dans les deux sens. Vous pouvez donc commencer une migration par fichiers et la terminer par une migration depuis un fournisseur, ou l'inverse, sans importer deux fois le même enregistrement.## Importer les photos de documents, les vidéos et les selfies comme justificatifsPour `import_type=user_verification`, vous pouvez importer les photos originales des documents, les vidéos de capture du document et de détection du vivant, ainsi que l'image du selfie provenant du fournisseur précédent.Utilisez ces colonnes canoniques :| Justificatif | Colonne privilégiée | Solution de repli pour petits imports | Enregistré dans Didit en tant que | | - | - | - | - | | Image recto du document | `document_front_url` | `document_front_base64` | Image recto OCR de la Vérification d'identité | | Image verso du document | `document_back_url` | `document_back_base64` | Image verso OCR de la Vérification d'identité | | Image selfie / détection du vivant | `selfie_url` | `selfie_base64` | Image de référence de correspondance faciale et de détection du vivant | | Vidéo du recto du document | `document_front_video_url` | URL uniquement | Vidéo recto OCR de la Vérification d'identité | | Vidéo du verso du document | `document_back_video_url` | URL uniquement | Vidéo verso OCR de la Vérification d'identité | | Vidéo de détection du vivant | `liveness_video_url` | URL uniquement | Vidéo de capture de correspondance faciale et de détection du vivant |Pour les migrations volumineuses, utilisez des **URL HTTPS**. Didit télécharge chaque fichier, vérifie que l'URL est sûre, stocke une copie appartenant à Didit et la rattache à la session importée. Les images sont compressées ; les vidéos sont stockées telles quelles. Le base64 intégré est accepté pour les images lors des petits imports, mais les **vidéos doivent toujours être fournies sous forme d'URL** : le base64 augmenterait chaque vidéo d'environ \~33% et dépasserait rapidement la limite d'import par fichier.Exemple de ligne NDJSON avec des URL de médias hébergés par le fournisseur :```json theme={null} { "external_id": "applicant-123", "vendor_data": "user-42", "created_at": "2025-01-12T10:30:00Z", "status": "Approved", "email": "user@example.com", "phone": "+34687020083", "first_name": "Jane", "last_name": "Doe", "date_of_birth": "1990-05-15", "document_type": "P", "issuing_state": "USA", "document_number": "123456789", "expiration_date": "2030-01-15", "document_front_url": "https://provider-export.example.com/files/applicant-123-front.jpg", "document_back_url": "https://provider-export.example.com/files/applicant-123-back.jpg", "selfie_url": "https://provider-export.example.com/files/applicant-123-selfie.jpg", "document_front_video_url": "https://provider-export.example.com/files/applicant-123-front.webm", "document_back_video_url": "https://provider-export.example.com/files/applicant-123-back.webm", "liveness_video_url": "https://provider-export.example.com/files/applicant-123-liveness.mp4", "reject_reasons_json": "[]", "provider_metadata_json": "{\"source\":\"sumsub-export\"}" } ```Règles importantes concernant les médias :- Les URL doivent utiliser `https`. - Les URL ne doivent pas résoudre vers des adresses IP privées, localhost, des plages d'adresses de liaison locale ni des hôtes de métadonnées internes. - Les images acceptent soit une colonne URL, soit leur solution de repli `*_base64` ; le base64 est prioritaire lorsque les deux sont renseignés. Les vidéos ne sont acceptées que sous forme d'URL : il n'existe pas de colonne `*_video_base64`. - Les vidéos doivent être au format `mp4`, `webm` ou `mov`, et chaque vidéo ne peut pas dépasser **10 Mo**. Les fichiers plus volumineux ou qui ne sont pas des vidéos sont rejetés comme erreurs de ligne. - Didit applique des délais d'expiration de connexion et de lecture, une taille maximale de fichier, et interdit les nouvelles tentatives illimitées. - Les échecs de téléchargement des médias sont enregistrés comme erreurs de ligne afin que le reste de l'import puisse se poursuivre. - Si vous ne disposez pas de médias provenant du fournisseur, laissez ces colonnes vides. Didit importe tout de même la décision structurée et les champs du document. - Les images et vidéos importées servent de justificatifs pour l'examen des données historiques. Par défaut, Didit ne relance pas l'OCR, la détection du vivant ni l'analyse de fraude documentaire sur les médias historiques importés. Prompt d'import de vérification des utilisateurs Copier le prompt dans le presse-papiers \

\`You are helping migrate historical User Verification (KYC) sessions into Didit.

Goal:
Transform the customer's Sumsub, MetaMap, or provider export into Didit's canonical verification import file, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=user_verification
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- DIDIT_WORKFLOW_ID for a User Verification workflow
\- Provider export file or API output

Canonical columns:
external_id, vendor_data, created_at, status, email, phone, first_name, last_name, date_of_birth, gender, nationality, document_type, issuing_state, document_number, personal_number, expiration_date, document_front_url, document_back_url, selfie_url, document_front_base64, document_back_base64, selfie_base64, document_front_video_url, document_back_video_url, liveness_video_url, is_blocklisted, reject_reasons_json, tags, provider_metadata_json

Rules:
\- phone is optional and accepts international format (for example +34687020083); it is stored on the imported session.
\- external_id must be the provider's unique verification/applicant id.
\- vendor_data must be the customer's stable user id. If absent, use the provider identity/user id.
\- status must be Approved, Declined, In Review, or Expired.
\- date_of_birth and expiration_date must use YYYY-MM-DD.
\- created_at must be ISO 8601.
\- nationality and issuing_state must be ISO-3166 alpha-3, for example USA, ESP, BRA.
\- document_type must use Didit codes: P, ID, DL, RP, SSC, HIC, WP, TC, VISA, PSC, BC, OTHER.
\- reject_reasons_json must be a JSON array. provider_metadata_json must be a JSON object.
\- Use document_front_url, document_back_url, and selfie_url when the provider can export evidence images. Use HTTPS media URLs for large imports. Avoid inline base64 unless the import is small.
\- Use document_front_video_url, document_back_video_url, and liveness_video_url to import capture videos. Videos must be mp4, webm, or mov and at most 10 MB each; otherwise the row is rejected.
\- If only one document side exists, fill document_front_url and leave document_back_url empty.
\- Never call the import API with provider credentials. The customer downloads provider data themselves.
\- The import is idempotent by external_id inside one Didit application, so retries are safe.

Steps:
1\. Inspect the provider export schema.
2\. Map each provider row to the canonical fields.
3\. Write NDJSON for large files; one JSON object per line.
4\. Validate the first 10 rows locally before uploading.
5\. Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=user_verification" \
-F "workflow_id=$DIDIT_WORKFLOW_ID" \
-F "file=@didit-import.ndjson"
6\. Poll until status is COMPLETED or FAILED.
7\. If failed_count is greater than 0, fetch /errors/ and produce a corrected file containing only failed rows.

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A short summary of created, skipped, and failed rows.`

\
Coller dans Prompt d'import de vérification d'entreprise Copier le prompt dans le presse-papiers \

\`You are helping migrate historical Business Verification (KYB) sessions into Didit.

Goal:
Transform the customer's KYB provider export into Didit's canonical business verification import file, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=business_verification
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- DIDIT_WORKFLOW_ID for a Business Verification workflow
\- Provider export file or API output

Canonical business columns:
external_id, vendor_data, created_at, status, company_name, registration_number, country_code, registry_status, verification_status, company_type, tax_number, risk_level, incorporation_date, registered_address, is_from_registry, officers_json, beneficial_owners_json, provider_metadata_json, tags

Rules:
\- external_id must be the provider's unique business verification id.
\- vendor_data must be the customer's stable business id.
\- status must be Approved, Declined, In Review, or Expired.
\- country_code must be ISO-3166 alpha-3.
\- officers_json and beneficial_owners_json must be JSON arrays of objects.
\- provider_metadata_json must be a JSON object.
\- The import is idempotent by external_id inside one Didit application.

Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=business_verification" \
-F "workflow_id=$DIDIT_WORKFLOW_ID" \
-F "file=@didit-business-import.ndjson"

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A short summary of created, skipped, and failed rows.`

\
Coller dans Prompt d'import des règles de statut personnalisées Copier le prompt dans le presse-papiers \

\`You are helping import custom status rules into a Didit workflow.

Goal:
Transform the customer's policy spreadsheet into Didit's feature_status_rules format, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=status_rules
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- DIDIT_WORKFLOW_ID for the workflow to update
\- A policy spreadsheet or JSON policy definition

Canonical status-rule columns:
feature, rules_json, mode

Rules:
\- feature must be a Didit feature key such as OCR, LIVENESS, FACE_MATCH, AML, KYB_REGISTRY, KYB_DOCUMENTS, or KYB_KEY_PEOPLE.
\- rules_json must be a JSON array of rule objects.
\- Each rule needs field, operator, status, and usually value.
\- mode is replace or append. Default is replace.
\- Do not reference status fields such as kyc.status; status rules compute status and must use other report fields.

Example rules_json:
\[{"field":"kyc.issuing_state","operator":"in","value":["VEN","IRN"],"status":"In Review"}]

Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=status_rules" \
-F "workflow_id=$DIDIT_WORKFLOW_ID" \
-F "file=@didit-status-rules.csv"

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A summary of updated and failed rule rows.`

\
Coller dans Prompt d'import de transactions Copier le prompt dans le presse-papiers \

\`You are helping migrate historical transaction monitoring records into Didit.

Goal:
Transform the customer's legacy transaction monitoring export into Didit's canonical transaction import file, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=transactions
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- A transaction export file or API output

Canonical transaction columns:
transaction_id, transaction_at, transaction_category, direction, amount, currency, currency_kind, amount_in_default_currency, default_currency, payment_details, payment_reference_id, action_type, status, score, severity, subject_json, counterparty_json, custom_properties_json, provider_results_json, travel_rule_json, network_snapshot_json, metadata_json

Rules:
\- transaction_id is required and is idempotent per Didit application.
\- transaction_category must be one of Didit's transaction categories, for example finance, kyc, travelRule, userPlatformEvent, gamblingBet, gamblingLimitChange, gamblingBonusChange, or auditTrailEvent.
\- direction must be INBOUND or OUTBOUND.
\- status must be APPROVED, IN_REVIEW, DECLINED, or AWAITING_USER.
\- subject_json must include vendor_data and full_name.
\- counterparty_json is optional but should be included when the legacy provider has it.
\- provider_results_json must be a JSON array.
\- travel_rule_json, network_snapshot_json, custom_properties_json, and metadata_json must be JSON objects when present.

Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=transactions" \
-F "file=@didit-transactions.ndjson"

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A summary of created, skipped, and failed transaction rows.`

\
Coller dans ## Suivre la progression```bash theme={null} curl https://verification.didit.me/v3/session/imports/IMPORT_ID/ \ -H "x-api-key: YOUR_API_KEY" ```La réponse comprend `status`, `import_type`, `total_rows`, `processed_rows`, `created_count`, `updated_count`, `skipped_count`, `failed_count` et `checkpoint_row`.## Télécharger les erreurs de ligne```bash theme={null} curl https://verification.didit.me/v3/session/imports/IMPORT_ID/errors/ \ -H "x-api-key: YOUR_API_KEY" ```Chaque erreur comprend `row_number`, `external_id`, `error` et `raw_row`, afin que vous puissiez corriger uniquement les lignes en échec et les réessayer.## Protection contre les abusLes tâches d'import historique via `POST /v3/session/imports/` sont désactivées par défaut. Didit active cette fonctionnalité pour chaque organisation après examen, car ces tâches peuvent traiter des millions de lignes et télécharger des médias. Les imports de données opérationnelles courantes décrits dans ce guide, à savoir la création d'utilisateurs, la création d'entreprises, le téléversement de visages de profil, le téléversement de listes de blocage de visages ou l'ajout d'entrées dans une liste, ne nécessitent pas d'activation spéciale pour la migration, au-delà des autorisations habituelles de la clé API, de la disponibilité des produits et des limites de débit des endpoints concernés.Les tâches d'import historique s'exécutent aussi sur des processus de traitement isolés, avec des limites de taille de fichier, des quotas de lignes, des URL de médias utilisant exclusivement HTTPS, un blocage des URL vers les réseaux privés, une limite de 4 tâches d'import actives par application et la capture des erreurs ligne par ligne.## Statuts canoniques| Résultat du fournisseur | Statut Didit | | - | - | | Approuvé / Vert / Vérifié | `Approved` | | Refusé / Rouge / Rejeté | `Declined` | | Examen manuel / En attente / Examen requis | `In Review` | | Incomplet / Init / Ligne historique inconnue | `Expired` |## IdempotenceDidit utilise `external_id` comme clé d'idempotence des imports pour la vérification des utilisateurs et la vérification d'entreprise, dans le périmètre de chaque application. Les imports de transactions utilisent `transaction_id` par application. Réessayer le même fichier ignore les lignes déjà importées et crée les lignes qui n'ont pas encore été traitées.## Importer des utilisateurs, des visages de profil et des listes de blocageUtilisez ces chemins lorsque vous ne recréez pas une session de vérification terminée :### Importer des profils utilisateurCréez des utilisateurs avec [`POST /v3/users/create/`](https://docs.didit.me/fr/management-api/users/create) ou avec l'import CSV de la Business Console dans [Importer et exporter des utilisateurs](https://docs.didit.me/fr/entities/users/import-export.md). Cette opération crée ou met à jour uniquement le profil `VendorUser`. Elle ne crée pas de session de vérification, de décision KYC, de rapport de document, d'avertissement ni d'historique de webhooks.Utilisez cette méthode lorsque vous voulez que Didit connaisse le client avant les vérifications futures, ou lorsque vous devez renseigner rétroactivement des champs de type CRM, comme `display_name`, des tags ou des métadonnées.### Téléverser des visages de profil de confianceUne fois qu'un utilisateur existe, téléversez un visage de profil de confiance avec [`POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/`](https://docs.didit.me/fr/management-api/users/upload-face). Cette opération associe une preuve biométrique au profil utilisateur et l'indexe pour la détection des doublons et la recherche faciale.Cette opération **ne** place **pas** le visage sur liste de blocage. Elle est utile lorsque vous disposez d'une image de profil de confiance issue d'un fournisseur KYC précédent et que vous souhaitez que les prochaines vérifications Didit la comparent à cette image.### Importer des listes de blocage et d'autorisation de visagesPour bloquer ou autoriser directement un visage, utilisez [`POST /v3/lists/{list_uuid}/entries/face-upload/`](https://docs.didit.me/fr/management-api/lists/upload-face) avec une liste de type facial. Didit extrait l'embedding biométrique et enregistre une entrée de liste.Utilisez cette méthode pour des images de fraudeurs connus, des visages de confiance figurant sur des listes d'autorisation ou la migration de listes de fraude d'un fournisseur. Si le visage provient d'une session Didit existante, privilégiez [`POST /v3/lists/{list_uuid}/entries/`](https://docs.didit.me/fr/management-api/lists/create-entry) avec `reference_session_id` : Didit extrait le bon visage à partir de la session et relie l'entrée à sa source.### Importer des listes d'utilisateurs, d'entreprises, de documents, de portefeuilles, d'e-mails, de téléphones, d'adresses IP ou d'appareilsUtilisez [`POST /v3/lists/{list_uuid}/entries/`](https://docs.didit.me/fr/management-api/lists/create-entry) pour les valeurs de liste autres que les visages. C'est la bonne méthode pour les listes de blocage et d'autorisation fournies par un fournisseur, les listes de rétrofacturation, les adresses de portefeuille, les adresses IP à risque connues, les empreintes d'appareil, les numéros de document, les e-mails, les téléphones, les utilisateurs ou les entreprises.## Prochaines étapes> [card] [Importer des utilisateurs](https://docs.didit.me/fr/entities/users/import-export.md) > > Chargez les profils utilisateur et associez-leur des visages de profil de confiance.> [card] [Importer des entreprises](https://docs.didit.me/fr/entities/businesses/import-export.md) > > Chargez les profils d'entreprise avant de lancer une vérification KYB.> [card] [Téléverser un visage de profil](https://docs.didit.me/fr/management-api/users/upload-face.md) > > Associez des images de visage de confiance aux utilisateurs importés.> [card] [Ajouter un visage à une liste](https://docs.didit.me/fr/management-api/lists/upload-face.md) > > Ajoutez des visages aux listes de blocage ou d'autorisation.> [card] [Créer une entrée de liste](https://docs.didit.me/fr/management-api/lists/create-entry.md) > > Importez des téléphones, e-mails, portefeuilles, documents, adresses IP, appareils, utilisateurs ou entreprises dans des listes.> [card] [Limites de débit](https://docs.didit.me/fr/integration/rate-limiting.md) > > Concevez des boucles de migration sûres et gérez les nouvelles tentatives. ## OpenAPI ````yaml fr/openapi-25.json POST /v3/session/imports/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de vérification d'identité. Authentifiez-vous avec l'en-tête x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/imports/: post: tags: - Sessions summary: Créer une tâche d'importation de vérification description: "Créer une tâche d'importation asynchrone pour les sessions historiques de Vérification des utilisateurs, les sessions de Vérification d'entreprise (KYB), les enregistrements de surveillance des transactions ou les règles de statut personnalisé de workflow. Définissez `source=provider` pour migrer depuis un autre prestataire\_: Didit lit Sumsub, Onfido, Persona et ComplyCube avec votre clé en lecture seule, lit les enregistrements Veriff, iDenfy et MetaMap selon les identifiants que vous téléversez dans `file`, et importe un fichier d'exportation au format de Didit pour les autres prestataires. Les identifiants d'enregistrement sont préfixés par prestataire (`sumsub:`) afin qu'une réexécution ignore tout ce qui se trouve déjà dans Didit, et un enregistrement importé via un fichier avec l'identifiant brut du prestataire est également reconnu, dans les deux sens, de sorte que passer d'une importation par fichier à une migration de prestataire n'importe jamais un enregistrement deux fois. Une application peut exécuter jusqu'à 4 tâches d'importation simultanément\_; une tâche interrompue par un déploiement ou un redémarrage de worker reprend d'elle-même à partir de sa dernière ligne importée. Les importations sont désactivées par défaut et doivent être activées par organisation par Didit." operationId: post_v3_session_imports_create requestBody: required: true content: multipart/form-data: schema: type: object properties: import_type: type: string enum: - user_verification - business_verification - status_rules - transactions default: user_verification description: >- Ce qu'il faut importer : sessions historiques de vérification des utilisateurs, sessions historiques de vérification d'entreprise, règles de statut personnalisées de workflow ou enregistrements historiques de surveillance des transactions. workflow_id: type: string format: uuid description: >- UUID du workflow auquel les sessions importées ou les règles de statut doivent être rattachées. Requis pour user_verification, business_verification et status_rules. À omettre pour les transactions. source_format: type: string enum: - csv - ndjson description: >- Optionnel. Déduit de l'extension du fichier téléversé lorsqu'il est omis. file: type: string format: binary description: >- Fichier CSV ou NDJSON canonique. Utilisez NDJSON pour les importations volumineuses. Taille maximale de téléversement : 25 Mo (utilisez `source_file_url` pour les fichiers plus volumineux). Mutuellement exclusif avec `source_file_url`. source_file_url: type: string format: uri description: >- Alternative au téléversement de fichier. Doit être une URL HTTPS résolvant vers une adresse publique (les réseaux privés/de bouclage sont rejetés). Mutuellement exclusif avec `file`. source: type: string enum: - file - provider description: >- `provider` définit ceci comme une migration depuis un autre fournisseur de vérification d'identité. Omettez pour une importation de fichiers. provider: type: string enum: - sumsub - jumio - veriff - onfido - persona - metamap - socure - idnow - shufti - idenfy - ondato - trulioo - au10tix - complycube - other description: >- Source de migration, obtenue via `GET /v3/session/imports/providers/`. Requis lorsque `source` vaut `provider`. credentials: type: object additionalProperties: type: string description: >- La clé en lecture seule du fournisseur, contenant les noms de champs listés par `credential_fields`. Chiffrée au repos, jamais renvoyée et effacée à la fin de l'importation. Envoyez-la sous forme de chaîne JSON dans du multipart. options: type: object properties: region: type: string description: >- La région du fournisseur, l'une de ses `regions` (Onfido : `eu`, `us`, `ca`). status_mapping: type: object additionalProperties: type: string enum: - Approved - Declined - In Review - Expired - Not Finished - Abandoned description: >- Modifications du mappage de statuts par défaut du fournisseur : statut source vers statut Didit. `Not Finished` et `Abandoned` sont ignorés et comptabilisés, jamais importés. dry_run: type: boolean default: false description: >- Compter ce que la migration importerait (par statut, déjà dans Didit, même personne, non terminé) sans rien écrire. La tâche se termine avec le statut `READY` ; démarrez-la avec `POST /v3/session/imports/{importId}/start/`. face_templates: type: boolean default: false description: >- Générez des gabarits biométriques à partir des selfies importés et recherchez-les parmi les visages et la liste de blocage de l'application. Les correspondances sont signalées uniquement pour examen. Nécessite `lawful_basis_confirmed`. lawful_basis_confirmed: type: boolean default: false description: >- Confirme que vous disposez d'une base légale pour partager ces selfies avec Didit en tant que sous-traitant. application/json: schema: type: object required: - source_file_url properties: import_type: type: string enum: - user_verification - business_verification - status_rules - transactions default: user_verification description: >- Ce qu'il faut importer : sessions historiques de vérification des utilisateurs, sessions historiques de vérification d'entreprise, règles de statut personnalisées de workflow ou enregistrements historiques de surveillance des transactions. workflow_id: type: string format: uuid description: >- UUID du workflow auquel les sessions importées ou les règles de statut doivent être rattachées. Requis pour user_verification, business_verification et status_rules. À omettre pour les transactions. source_format: type: string enum: - csv - ndjson description: >- Optionnel. Déduit de l'extension de fichier de l'URL lorsqu'il est omis. source_file_url: type: string format: uri description: >- Alternative au téléversement de fichier. Doit être une URL HTTPS résolvant vers une adresse publique (les réseaux privés/de bouclage sont rejetés). Mutuellement exclusif avec `file`. source: type: string enum: - file - provider description: >- `provider` définit ceci comme une migration depuis un autre fournisseur de vérification d'identité. Omettez pour une importation de fichiers. provider: type: string enum: - sumsub - jumio - veriff - onfido - persona - metamap - socure - idnow - shufti - idenfy - ondato - trulioo - au10tix - complycube - other description: >- Source de migration, obtenue via `GET /v3/session/imports/providers/`. Requis lorsque `source` vaut `provider`. credentials: type: object additionalProperties: type: string description: >- La clé en lecture seule du fournisseur, contenant les noms de champs listés par `credential_fields`. Chiffrée au repos, jamais renvoyée et effacée à la fin de l'importation. Envoyez-la sous forme de chaîne JSON dans du multipart. options: type: object properties: region: type: string description: >- La région du fournisseur, l'une de ses `regions` (Onfido : `eu`, `us`, `ca`). status_mapping: type: object additionalProperties: type: string enum: - Approved - Declined - In Review - Expired - Not Finished - Abandoned description: >- Modifications du mappage de statuts par défaut du fournisseur : statut source vers statut Didit. `Not Finished` et `Abandoned` sont ignorés et comptabilisés, jamais importés. dry_run: type: boolean default: false description: >- Compter ce que la migration importerait (par statut, déjà dans Didit, même personne, non terminé) sans rien écrire. La tâche se termine avec le statut `READY` ; démarrez-la avec `POST /v3/session/imports/{importId}/start/`. face_templates: type: boolean default: false description: >- Générez des gabarits biométriques à partir des selfies importés et recherchez-les parmi les visages et la liste de blocage de l'application. Les correspondances sont signalées uniquement pour examen. Nécessite `lawful_basis_confirmed`. lawful_basis_confirmed: type: boolean default: false description: >- Confirme que vous disposez d'une base légale pour partager ces selfies avec Didit en tant que sous-traitant. examples: URL-based import: value: import_type: user_verification workflow_id: 9f9b1234-aaaa-bbbb-cccc-1234567890ab source_file_url: https://files.example.com/exports/sessions.ndjson responses: '201': description: >- Tâche d'importation acceptée. Interrogez l'`uuid` renvoyé jusqu'à ce que le `status` soit `COMPLETED` ou `FAILED`. content: application/json: schema: $ref: '#/components/schemas/SessionImportJob' examples: Job accepted: value: uuid: 3f9c1a2b-4d5e-4f60-8a7b-9c0d1e2f3a4b status: PENDING import_type: user_verification source_format: ndjson source_filename: sessions.ndjson total_rows: 0 processed_rows: 0 checkpoint_row: 0 created_count: 0 updated_count: 0 skipped_count: 0 failed_count: 0 total_media_bytes: 0 last_error: null created_at: '2026-05-17T08:42:11Z' updated_at: '2026-05-17T08:42:11Z' started_at: null completed_at: null '400': description: >- Workflow, type de fichier, taille de fichier, URL source ou combinaison de sélecteurs non valide. Une migration dont le fournisseur refuse la clé renvoie `code` (`invalid_credentials`, `missing_permission`, `wrong_region`, `provider_unavailable`, `rate_limited`, `ids_required`, `record_not_found`), `missing_permissions` et `suggested_region`. content: application/json: examples: Invalid workflow: value: workflow_id: - Invalid workflow_id. Workflow required: value: workflow_id: - This field is required for this import type. Wrong file type: value: file: - Only CSV and NDJSON files are supported. File too large: value: file: - Import file exceeds the maximum allowed size. No source: value: file: - Upload a file or provide source_file_url. Both sources: value: file: - Use either file or source_file_url, not both. '403': description: >- Importations non activées, application sandbox ou clé API manquante (une clé erronée, révoquée ou expirée renvoie `401`). Les importations de vérifications sont désactivées par défaut et doivent être activées par Didit pour chaque organisation. content: application/json: examples: Imports not enabled: value: detail: >- Verification imports are not enabled for this organization. Sandbox: value: detail: >- Verification imports are not enabled for sandbox applications. Bad API key: value: detail: You do not have permission to perform this action. '429': description: >- L'application possède déjà 4 tâches d'importation actives (PENDING/PROCESSING/PAUSED), soit le nombre maximal qu'elle peut exécuter simultanément. Attendez que l'une d'elles se termine avant d'en démarrer une autre. content: application/json: examples: Active job: value: detail: >- This application already has 4 active import jobs, the most it can run at once. Wait for one to finish before starting another. security: - ApiKeyAuth: [] x-codeSamples: - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.sessions.imports.create( import_type="user_verification", workflow_id="9f9b1234-aaaa-bbbb-cccc-1234567890ab", source_file_url="https://files.example.com/exports/sessions.ndjson", ) print(result) - lang: javascript label: Node.js source: |- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.sessions.imports.create({ import_type: "user_verification", workflow_id: "9f9b1234-aaaa-bbbb-cccc-1234567890ab", source_file_url: "https://files.example.com/exports/sessions.ndjson", }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Imports.Create(ctx, didit.SessionsImportsCreateParams{\n\tImportType: didit.Some(didit.SessionsImportsCreateParamsImportType(\"user_verification\")),\n\tWorkflowID: didit.String(\"9f9b1234-aaaa-bbbb-cccc-1234567890ab\"),\n\tSourceFileURL: didit.String(\"https://files.example.com/exports/sessions.ndjson\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.SessionsImportsCreateParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.sessions().imports().create(SessionsImportsCreateParams.builder() .importType(SessionsImportsCreateParams.ImportType.of("user_verification")) .workflowId("9f9b1234-aaaa-bbbb-cccc-1234567890ab") .sourceFileUrl("https://files.example.com/exports/sessions.ndjson") .build()); System.out.println(result); - lang: php label: PHP source: |- sessions->imports->create([ 'import_type' => 'user_verification', 'workflow_id' => '9f9b1234-aaaa-bbbb-cccc-1234567890ab', 'source_file_url' => 'https://files.example.com/exports/sessions.ndjson', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.sessions.imports.create( import_type: "user_verification", workflow_id: "9f9b1234-aaaa-bbbb-cccc-1234567890ab", source_file_url: "https://files.example.com/exports/sessions.ndjson" ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Sessions.Imports.CreateAsync(new SessionsImportsCreateParams { ImportType = new SessionsImportsCreateParamsImportType("user_verification"), WorkflowId = "9f9b1234-aaaa-bbbb-cccc-1234567890ab", SourceFileUrl = "https://files.example.com/exports/sessions.ndjson", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: SessionImportJob: type: object required: - uuid - status - import_type - source_format - source_filename - total_rows - processed_rows - created_count - updated_count - skipped_count - failed_count properties: uuid: type: string format: uuid description: >- Identifiant de la tâche d'importation. Utilisez cette valeur pour suivre la progression et récupérer les erreurs de ligne. status: type: string enum: - PENDING - PROCESSING - COMPLETED - FAILED - PAUSED - CANCELLED - READY import_type: type: string enum: - user_verification - business_verification - status_rules - transactions source_format: type: string enum: - csv - ndjson source_filename: type: string total_rows: type: integer format: int64 processed_rows: type: integer format: int64 checkpoint_row: type: integer format: int64 created_count: type: integer format: int64 updated_count: type: integer format: int64 skipped_count: type: integer format: int64 failed_count: type: integer format: int64 total_media_bytes: type: integer format: int64 last_error: type: string nullable: true created_at: type: string format: date-time updated_at: type: string format: date-time started_at: type: string format: date-time nullable: true completed_at: type: string format: date-time nullable: true state: type: string enum: - ready - queued - running - paused - completed - errors - failed - cancelled description: >- L'état de la tâche tel qu'affiché dans la console ; `errors` correspond à une tâche terminée avec des lignes rejetées. source: type: string enum: - file - api - provider provider: type: string description: >- Source de migration ; vide pour une importation par fichier ou par API. provider_options: type: object credential_hint: type: string description: >- Les premiers caractères de la clé détenue par la migration. La clé elle-même n'est jamais renvoyée. credentials_expires_at: type: string format: date-time nullable: true resumes_at: type: string format: date-time nullable: true description: >- Moment où une tâche mise en pause par la limite de débit du fournisseur reprend d'elle-même. status_mapping: type: object additionalProperties: type: string is_dry_run: type: boolean dry_run_summary: type: object description: >- Ce qu'une exécution à blanc a trouvé : `total`, `by_status`, `already_in_didit`, `same_person`, `not_finished`, `failed`, `unmapped_statuses`. face_templates_enabled: type: boolean lawful_basis_confirmed_at: type: string format: date-time nullable: true not_finished_count: type: integer format: int64 same_person_count: type: integer format: int64 face_templates_count: type: integer format: int64 face_duplicates_count: type: integer format: int64 face_blocklist_hits_count: type: integer format: int64 created_by_name: type: string nullable: true created_by_email: type: string nullable: true securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- La clé API de votre application, issue de Développeurs -> Clés API dans la Business Console. La clé principale dispose d'un accès complet. Une clé nommée peut être restreinte : aucun, lecture ou écriture par ressource, limitée à certains workflows ou aux sessions approuvées, à une liste d'adresses IP et à une date d'expiration. 401 signifie que la clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a été envoyée, que la clé n'a pas accès à cette ressource ou action, ou que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur une route de session signifie que la session est hors des workflows ou des statuts de la clé. Une clé sans accès aux médias reçoit les URL d'images, de vidéos et de PDF à null, et une clé sans accès en écriture aux sessions reçoit les liens et tokens de session à null. Voir https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.