Importer des vérifications depuis un autre fournisseur

Python

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)

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);

ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()

result, err := client.Sessions.Imports.Create(ctx, didit.SessionsImportsCreateParams{
	ImportType:    didit.Some(didit.SessionsImportsCreateParamsImportType("user_verification")),
	WorkflowID:    didit.String("9f9b1234-aaaa-bbbb-cccc-1234567890ab"),
	SourceFileURL: didit.String("https://files.example.com/exports/sessions.ndjson"),
})
if err != nil {
	log.Fatal(err)
}
fmt.Printf("%+v\n", result)

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);

<?php

require 'vendor/autoload.php';

use Didit\DiditClient;

// Reads DIDIT_API_KEY.
$didit = new DiditClient();

$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',
]);
print_r($result->toArray());

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

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));

curl --request POST \
  --url https://verification.didit.me/v3/session/imports/ \
  --header 'Content-Type: multipart/form-data' \
  --header 'x-api-key: <api-key>' \
  --form import_type=user_verification \
  --form workflow_id=3c90c3cc-0d44-4b50-8888-8dd25736052a \
  --form file=@example-file \
  --form 'source_file_url=<string>' \
  --form 'credentials={}' \
  --form 'options={
  "region": "<string>"
}' \
  --form 'status_mapping={}' \
  --form dry_run=false \
  --form face_templates=false \
  --form lawful_basis_confirmed=false

{
  "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
}

POST

session

imports

Python

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)

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);

ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()

result, err := client.Sessions.Imports.Create(ctx, didit.SessionsImportsCreateParams{
	ImportType:    didit.Some(didit.SessionsImportsCreateParamsImportType("user_verification")),
	WorkflowID:    didit.String("9f9b1234-aaaa-bbbb-cccc-1234567890ab"),
	SourceFileURL: didit.String("https://files.example.com/exports/sessions.ndjson"),
})
if err != nil {
	log.Fatal(err)
}
fmt.Printf("%+v\n", result)

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);

<?php

require 'vendor/autoload.php';

use Didit\DiditClient;

// Reads DIDIT_API_KEY.
$didit = new DiditClient();

$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',
]);
print_r($result->toArray());

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

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));

curl --request POST \
  --url https://verification.didit.me/v3/session/imports/ \
  --header 'Content-Type: multipart/form-data' \
  --header 'x-api-key: <api-key>' \
  --form import_type=user_verification \
  --form workflow_id=3c90c3cc-0d44-4b50-8888-8dd25736052a \
  --form file=@example-file \
  --form 'source_file_url=<string>' \
  --form 'credentials={}' \
  --form 'options={
  "region": "<string>"
}' \
  --form 'status_mapping={}' \
  --form dry_run=false \
  --form face_templates=false \
  --form lawful_basis_confirmed=false

{
  "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
}

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

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 fournisseur

Didit 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 migration

Décidez si vous importez l’historique, les profils, les visages, les listes, les transactions ou les règles.
Exportez vous-même les données de l’ancien fournisseur. N’envoyez pas les clés API de l’ancien fournisseur à Didit.
Transformez l’export du fournisseur en modèle CSV ou NDJSON canonique de Didit correspondant.
Pour les migrations volumineuses, privilégiez NDJSON et découpez les données en fichiers que vous pouvez réessayer indépendamment.
Créez la tâche d’import, puis suivez sa progression en interrogeant régulièrement son état.
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’import

Créez une tâche d’import avec une seule requête multipart :

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 :

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és

Il 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 <provider>:<id>, 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 justificatifs

Pour 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 :

{
  "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.

Suivre la progression

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

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 abus

Les 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`

Idempotence

Didit 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 blocage

Utilisez ces chemins lorsque vous ne recréez pas une session de vérification terminée :

Importer des profils utilisateur

Créez des utilisateurs avec POST /v3/users/create/ ou avec l’import CSV de la Business Console dans Importer et exporter des utilisateurs. 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 confiance

Une 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/

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

Pour bloquer ou autoriser directement un visage, utilisez POST /v3/lists/{list_uuid}/entries/face-upload/ 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/ 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’appareils

Utilisez POST /v3/lists/{list_uuid}/entries/ 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

Importer des utilisateurs

Chargez les profils utilisateur et associez-leur des visages de profil de confiance.

Importer des entreprises

Chargez les profils d’entreprise avant de lancer une vérification KYB.

Téléverser un visage de profil

Associez des images de visage de confiance aux utilisateurs importés.

Ajouter un visage à une liste

Ajoutez des visages aux listes de blocage ou d’autorisation.

Créer une entrée de liste

Importez des téléphones, e-mails, portefeuilles, documents, adresses IP, appareils, utilisateurs ou entreprises dans des listes.

Limites de débit

Concevez des boucles de migration sûres et gérez les nouvelles tentatives.

Autorisations

x-api-key

string

header

requis

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.

Corps

import_type

enum<string>

défaut:user_verification

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.

Options disponibles:

user_verification,

business_verification,

status_rules,

transactions

workflow_id

string<uuid>

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

enum<string>

Optionnel. Déduit de l'extension du fichier téléversé lorsqu'il est omis.

Options disponibles:

csv,

ndjson

file

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

string<uri>

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

enum<string>

provider définit ceci comme une migration depuis un autre fournisseur de vérification d'identité. Omettez pour une importation de fichiers.

Options disponibles:

file,

provider

provider

enum<string>

Source de migration, obtenue via GET /v3/session/imports/providers/. Requis lorsque source vaut provider.

Options disponibles:

sumsub,

jumio,

veriff,

onfido,

persona,

metamap,

socure,

idnow,

shufti,

idenfy,

ondato,

trulioo,

au10tix,

complycube,

other

credentials

object

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.

Show child attributes

options

object

Show child attributes

status_mapping

object

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.

Show child attributes

dry_run

boolean

défaut:false

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

boolean

défaut:false

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

boolean

défaut:false

Confirme que vous disposez d'une base légale pour partager ces selfies avec Didit en tant que sous-traitant.

Réponse

Tâche d'importation acceptée. Interrogez l'uuid renvoyé jusqu'à ce que le status soit COMPLETED ou FAILED.

uuid

string<uuid>

requis

Identifiant de la tâche d'importation. Utilisez cette valeur pour suivre la progression et récupérer les erreurs de ligne.

status

enum<string>

requis

Options disponibles:

PENDING,

PROCESSING,

COMPLETED,

FAILED,

PAUSED,

CANCELLED,

READY

import_type

enum<string>

requis

Options disponibles:

user_verification,

business_verification,

status_rules,

transactions

source_format

enum<string>

requis

Options disponibles:

csv,

ndjson

source_filename

string

requis

total_rows

integer<int64>

requis

processed_rows

integer<int64>

requis

created_count

integer<int64>

requis

updated_count

integer<int64>

requis

skipped_count

integer<int64>

requis

failed_count

integer<int64>

requis

checkpoint_row

integer<int64>

total_media_bytes

integer<int64>

last_error

string | null

created_at

string<date-time>

updated_at

string<date-time>

started_at

string<date-time> | null

completed_at

string<date-time> | null

state

enum<string>

L'état de la tâche tel qu'affiché dans la console ; errors correspond à une tâche terminée avec des lignes rejetées.

Options disponibles:

ready,

queued,

running,

paused,

completed,

errors,

failed,

cancelled

source

enum<string>

Options disponibles:

file,

api,

provider

provider

string

Source de migration ; vide pour une importation par fichier ou par API.

provider_options

object

credential_hint

string

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

string<date-time> | null

resumes_at

string<date-time> | null

Moment où une tâche mise en pause par la limite de débit du fournisseur reprend d'elle-même.

status_mapping

object

Show child attributes

is_dry_run

boolean

dry_run_summary

object

Ce qu'une exécution à blanc a trouvé : total, by_status, already_in_didit, same_person, not_finished, failed, unmapped_statuses.

face_templates_enabled

boolean

lawful_basis_confirmed_at

string<date-time> | null

not_finished_count

integer<int64>

same_person_count

integer<int64>

face_templates_count

integer<int64>

face_duplicates_count

integer<int64>

face_blocklist_hits_count

integer<int64>

created_by_name

string | null

created_by_email

string | null

Dernière modification le 7 novembre 2026

​Quel import utiliser ?

​Ce qui peut être migré depuis chaque fournisseur

​Flux de migration

​Créer une tâche d’import

​Champs de la requête

​Comment les enregistrements sont suivis et dédupliqués

​Importer les photos de documents, les vidéos et les selfies comme justificatifs

​Suivre la progression

​Télécharger les erreurs de ligne

​Protection contre les abus

​Statuts canoniques

​Idempotence

​Importer des utilisateurs, des visages de profil et des listes de blocage

​Importer des profils utilisateur

​Téléverser des visages de profil de confiance

​Importer des listes de blocage et d’autorisation de visages

​Importer des listes d’utilisateurs, d’entreprises, de documents, de portefeuilles, d’e-mails, de téléphones, d’adresses IP ou d’appareils

​Prochaines étapes

Importer des utilisateurs

Importer des entreprises

Téléverser un visage de profil

Ajouter un visage à une liste

Créer une entrée de liste

Limites de débit

Autorisations

Corps

Réponse

Quel import utiliser ?

Ce qui peut être migré depuis chaque fournisseur

Flux de migration

Créer une tâche d’import

Champs de la requête

Comment les enregistrements sont suivis et dédupliqués

Importer les photos de documents, les vidéos et les selfies comme justificatifs

Suivre la progression

Télécharger les erreurs de ligne

Protection contre les abus

Statuts canoniques

Idempotence

Importer des utilisateurs, des visages de profil et des listes de blocage

Importer des profils utilisateur

Téléverser des visages de profil de confiance

Importer des listes de blocage et d’autorisation de visages

Importer des listes d’utilisateurs, d’entreprises, de documents, de portefeuilles, d’e-mails, de téléphones, d’adresses IP ou d’appareils

Prochaines étapes