Comment identifier les étapes en échec dans un rapport JSON ID360

Lorsqu'une vérification ID360 retourne un statut KO, il est possible d’en analyser la cause grâce à la structure du fichier JSON. Voici les chemins à suivre pour retrouver les informations utiles.

Chemin JSON : finalizer_reports > validator_report > validations

Chaque validation représente une règle métier appliquée à une donnée.

Vérifier :

• is_valid: false → indique un échec
• ref : identifiant de la règle (ex. IDENTITY.FIRST_NAME.first_name)
• fields : données concernées

Exemple :

{
  "ref": "IDENTITY.FIRST_NAME.first_name",
  "is_valid": false,
  "fields": [...]
}

🎯 Utilité : Identifier quelles données utilisateur ont échoué aux contrôles.

⚠️ Subtilité : Lors de la comparaison du nom de famille, deux contrôles sont effectués : l’un sur le nom d’usage, l’autre sur le nom de naissance. Par conséquent, vous verrez apparaître deux fois le champ “ref”: “IDENTITY.NAME.name” dans le rapport. Si l’un des deux contrôles est validé, la comparaison du nom est à considérer comme réussie.

Chemin JSON : finalizer_reports > validator_report > comparisons

Ces blocs comparent des valeurs issues de plusieurs sources (documents vs saisie utilisateur, documents entre eux…).

Vérifier :

• is_equivalent: false → la comparaison a échoué
• ref : la règle concernée
• field1 et field2 : les deux valeurs comparées

Exemple :

{
  "ref": "KBIS.SIREN.siren",
  "is_equivalent": false,
  "field1": {...},
  "field2": {...}
}

🎯 Utilité : Détecter des incohérences entre documents ou avec les données saisies.

Chemin JSON : finalizer_reports > validator_report > customs

Ces contrôles sont propres au client ou à certaines typologies de documents.

Vérifier :

• is_valid: false → la règle personnalisée a échoué
• ref : nom de la règle
• fields : données analysées

Exemple :

{
  "ref": "IDENTITY_DOCUMENT.document_number",
  "is_valid": false,
  "fields": [...]
}

🎯 Utilité : Comprendre les échecs sur des règles spécifiques définies pour un client donné.

Chemin JSON : finalizer_reports > validator_report > scripts

Ces contrôles sont issus de scripts personnalisés.

Vérifier :

• is_valid: false → le contrôle personnalisé a échoué
• data ou documents : donnée(s) ou document(s) concerné(s).
• errors : raison de l'erreur en cas de false

Exemple :

{
"scripts": [{"result": true,
	     "version": "2023-12-01",
	     "data": ["phone_number"]
	    },{
	     "result": false,
	     "version": "1.0",
	     "documents": ["IDENTITY_DOCUMENT"],
	     "errors": [{"code": "VLD_ID_INVALID",
                         "message": "Id from id_document_result is ignored because the format is not recognized"}]
	  }]
}

🎯 Utilité : Comprendre les échecs sur des règles spécifiques définies pour un client donné.

Chemin JSON : steps

Le bloc steps contient les différentes étapes du parcours. Pour chaque step, vous devez :

• Lire le champ status
• Si la valeur est KO, parcourir la liste status_codes à l'intérieur de ce step pour en comprendre la ou les causes

Exemple :

"steps": {
  "id_document": {
    "status": "KO",
    "status_codes": [
      {
        "code": "MDL_INPUT_INVALID",
        "message": "No MRZ could be read on the uploaded image(s)"
      }
    ]
  }
}

🎯 Utilité : Permet d'isoler les étapes qui ont échoué et d'obtenir des détails contextuels sur les anomalies rencontrées.