Passer au contenu principal
POST
Python
Soumettez les identifiants saisis et les attributs d’identité déclarés, sélectionnez les vérifications à exécuter, et examinez chaque résultat séparément. Commencez par consulter Planifier une vérification de fraude pour vérifier les données requises et les frais estimés.

Choisir un profil

Fixez profile_version afin que les valeurs par défaut sélectionnées et la politique de décision soient explicites. Le profil par défaut est standard, version 2026-08-27. La version 2026-09-14 ajoute l’enrichissement social facultatif par e-mail et par téléphone, et enregistre chaque vérification terminée comme une session native de Vérification des utilisateurs. Dans cette version, les options payantes doivent être activées explicitement. La version 2026-09-14.1 active également les recherches d’identifiants dans le réseau mondial de détection de fraude pour les organisations du forfait Enterprise qui partagent leurs données à l’échelle mondiale. La version 2026-09-14.2 ajoute une vérification facultative de correspondance entre le selfie et le CPF pour le Brésil. Les versions antérieures conservent leur comportement d’origine. Les profils actuels prennent en charge le risque lié à l’e-mail, le risque lié au téléphone, le risque lié à l’IP, la validation en base de données lorsqu’elle est éligible, et l’historique réseau privé de votre application. La liaison d’identité fondée sur le selfie exige la version 2026-09-14.2. La sélectionner dans les versions antérieures renvoie not_available_in_profile_version.

Identité déclarée et contexte

Indiquez l’e-mail, le téléphone et les identifiants gouvernementaux dans subject.identifiers. Les identifiants gouvernementaux exigent leur pays de délivrance ; un émetteur peut également être nécessaire lorsque les numéros ne sont uniques qu’au sein d’une région. Indiquez les noms, la date de naissance, la nationalité et l’adresse dans subject.attributes. Ce sont des éléments déclarés à comparer lorsqu’une source sélectionnée les prend en charge, et non des faits vérifiés du seul fait de leur soumission. Utilisez context pour l’adresse IP de la tentative, le user agent, la finalité, le pays et toute attestation de consentement requise. Cela sépare les informations sur la tentative de vérification de celles sur la personne. Pour les contrôles biométriques pris en charge, fournissez subject.selfie au format JPEG, PNG ou WebP encodé en base64, jusqu’à 6 Mo. Une URI de données d’image correspondante est également acceptée. N’envoyez ni image de référence, ni URL distante, ni clé de stockage.

Selfie et identifiant déclaré

Sélectionnez biometric_identity, soumettez un identifiant tax_number brésilien et un selfie, puis confirmez context.consent_obtained. La vérification de référence vérifie si ce selfie appartient au titulaire du CPF déclaré. Un consentement absent renvoie consent_required, et les pays non pris en charge renvoient unsupported_region. Le module a un prix par vérification, fondé sur le tarif de validation en base de données de votre organisation ; consultez le forfait avant de l’exécuter. Lorsque la référence répond, identity_relationship.result vaut match, mismatch ou inconclusive. Une réponse non concluante exige un examen et n’est jamais traitée comme une non-correspondance. Le résultat établit uniquement le lien entre le selfie et le CPF. Il ne valide pas un nom ou une date de naissance soumis, ne fournit pas de preuve de détection du vivant, et ne recherche pas de visage sur Internet ni dans le réseau mondial de détection de fraude. Les noms et la date de naissance restent des éléments déclarés, sauf si une autre source sélectionnée fournit une preuve pour ces champs. Les délais d’attente dépassés et les erreurs de source sont des résultats indisponibles et ne sont pas facturés. Les réponses non concluantes obtenues sont facturées au même tarif que les vérifications de référence. Le selfie n’est ni inclus dans le résultat ni stocké comme média de session par cette vérification.

Sélectionner les vérifications

checks.include sélectionne les modules, et checks.exclude est prioritaire. Une liste include explicitement vide désactive toutes les opérations facultatives ; la normalisation s’exécute toujours. Si include est omis, les valeurs par défaut du profil épinglé sont utilisées. Les enrichissements sociaux par e-mail et par téléphone sont sélectionnés séparément avec email_social et phone_social. Ils exigent un identifiant valide et correspondant, et n’envoient pas d’OTP.

Lire les résultats sans les confondre

Chaque module indique son statut d’exécution, sa raison et ses unités facturables. not_requested, excluded_by_caller, missing_required_input et source_unavailable décrivent des issues différentes. Une source manquante n’est ni une non-correspondance d’identité ni un résultat de risque nul. attribute_evidence décrit les preuves au niveau des champs, tandis que risk sépare les dimensions d’identité, de contact, d’appareil, comportementale et de réseau de fraude. Un e-mail, un appareil ou un autre identifiant partagé est une connexion observée, et non une preuve que deux comptes appartiennent à la même personne ou qu’une fraude a été commise. recommendation est la recommandation de la vérification ; elle ne modifie pas le statut d’un autre enregistrement. Les résultats de l’enrichissement social apparaissent sous enrichment, les résultats indisponibles étant distincts des résultats terminés.

Réseau mondial de fraude

Sélectionnez networks_cross_org pour interroger les identifiants d’e-mail et de téléphone pris en charge, ainsi que les identifiants de document correctement qualifiés et dotés d’un espace de noms, dans le réseau partagé. La recherche nécessite le forfait Enterprise et que le mode de partage de votre organisation soit défini sur global. Sans ces conditions, le forfait signale le module avec available: false et availability_reason: "entitlement_required", et un contrôle qui le sélectionne l’ignore avec le statut skipped et la raison entitlement_required. La même raison s’applique lorsque Networks n’est pas activé pour votre organisation. Les applications sandbox ne sont pas soumises au forfait ni au mode de partage : avec un identifiant pris en charge, le module s’exécute et renvoie un résultat d’exemple vide. La recherche utilise le budget de lecture existant de l’organisation et enregistre un audit de la lecture. Elle n’entraîne aucun frais par recherche. La planification d’un contrôle n’interroge pas l’index partagé et ne consomme pas son budget de lecture. network.cross_organization contient signals_checked et les insights agrégés divulgués lorsque le contrôle se termine. Chaque information contient le type de signal, les classes de résultat, le nombre de contributeurs, la tranche de récence et, uniquement si la divulgation est activée, les catégories sectorielles. Il n’identifie jamais une autre organisation, un autre compte, une personne ou une autre vérification. Les résultats situés sous le seuil de divulgation sont omis ; une liste vide ne prouve pas l’absence d’antécédents de fraude. Un signal partagé divulgué déclenche une recommandation d’examen, jamais un rejet automatique ni une correspondance d’identité. Une recherche indisponible indique sa raison séparément d’une recherche terminée sans résultat. Si votre organisation perd plus tard l’accès inter-organisations, par exemple après un changement de forfait ou lorsque le partage n’est plus global, la récupération des résultats, les nouvelles tentatives et les détails de session masquent les agrégats partagés et les éléments de preuve de risque qui en découlent. La recommandation initiale reste une décision historique ; les lectures ne modifient pas le statut de la vérification.

Sessions, nouvelles tentatives et facturation

check_id permet de récupérer le résultat stocké via Récupérer un contrôle de fraude. Lorsqu’il est présent, request_id identifie sa session de vérification native. Les versions 2026-09-14, 2026-09-14.1 et 2026-09-14.2 créent toujours cette session, y compris lorsque seul l’historique du réseau privé est sélectionné. Réutiliser client_reference avec le même corps de requête renvoie le résultat initial sans nouvelle exécution ni nouveau frais tant que ce contrôle existe. Un corps différent avec la même référence renvoie 409. Si l’exécution est encore en cours, relancez la même requête après l’intervalle indiqué dans l’en-tête Retry-After de la réponse. La suppression de la vérification associée supprime également le résultat du contrôle de fraude ; la récupération renvoie alors 404. Un contrôle supprimé pendant son exécution ne peut pas publier un résultat finalisé. Les tarifs proviennent des tarifs prépayés ou contractuels actuels de votre organisation. Les modules indisponibles et ignorés ne sont pas facturés, et l’historique du réseau privé n’entraîne aucun frais par contrôle. Les contrôles sandbox utilisent des réponses d’exemple, sans appels payants aux fournisseurs ni frais.

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

subject
object
requis
client_reference
string

Votre propre référence pour cette vérification. Fait également office de clé d'idempotence : la réutiliser avec le même corps de requête renvoie la vérification d'origine sans réexécuter ni refacturer les modules ; la réutiliser avec un corps différent renvoie une erreur 409.

Required string length: 1 - 255
profile
string
défaut:standard

ID du profil d'orchestration. Le profil standard de Didit est utilisé par défaut.

Required string length: 1 - 64
profile_version
string

Épingler une version de profil gelée. Correspond par défaut à la version actuelle du profil.

Required string length: 1 - 32
context
object
checks
object
vendor_data
string
Maximum string length: 1000
metadata
any

Réponse

check_id
string<uuid>
requis
client_reference
string | null
requis
processing_status
enum<string>
requis
  • pending - En attente
  • running - En cours d'exécution
  • completed - Terminé
  • failed - Échoué
Options disponibles:
pending,
running,
completed,
failed
profile_id
string
requis
profile_version
string
requis
created_at
string<date-time>
requis
completed_at
string<date-time> | null
requis
inputs
object[]
requis
modules
object[]
requis
attribute_evidence
object[]
requis
compound_evidence
object[]
requis
risk
object[]
requis
network
object
requis
recommendation
enum<string>
requis
  • approve - Approuver
  • review - Examiner
  • reject - Rejeter
Options disponibles:
approve,
review,
reject
next_action
enum<string>
requis
  • none - Aucun
  • manual_review - Examen manuel
  • step_up - Vérification renforcée
  • resubmit_capture - Resoumettre la capture
Options disponibles:
none,
manual_review,
step_up,
resubmit_capture
decision_reasons
string[]
requis
coverage
object
requis
usage
object[]
requis
request_id
string<uuid>

Session de vérification native créée pour cette vérification.

enrichment
object
identity_relationship
object | null
vendor_data
string | null
metadata
unknown
Dernière modification le 7 novembre 2026