Passer au contenu principal
L’API Didit signale un échec au moyen d’un code de statut HTTP et, dans presque tous les cas, d’un corps JSON. Cette page détaille la signification de chaque statut, la structure du corps, les valeurs de code sur lesquelles vous pouvez vous baser pour votre logique conditionnelle, et les échecs que vous pouvez réessayer en toute sécurité. Fiez-vous d’abord au statut et à code lorsqu’il est présent, car le texte d’un message peut changer.

Codes de statut

Corps d’erreur

Les corps d’erreur n’ont pas tous la même enveloppe ; traitez-les donc avec prudence. Leur format dépend de la famille d’endpoints : Une erreur 500 peut ne comporter aucun corps JSON ; prévoyez donc la gestion d’un corps impossible à parser.

Erreurs de clé API

Pendant quelques minutes après la suppression d’une application, l’API répond avec application_deleted, puis elle rejette ensuite la clé comme n’importe quelle clé erronée. Ne réessayez pas : l’application et ses clés ont été supprimées. Consultez Authentification API et Clés API pour comprendre le fonctionnement des clés et de leurs limites.

Crédits insuffisants

Chaque famille d’API signale un solde insuffisant à sa manière : Dans le cadre d’un contrat, la création d’une session renvoie un code 403 avec "code": "contract_billing_suspended" lorsque les services payants sont suspendus pour votre organisation. Les applications sandbox ne sont jamais facturées et ignorent donc ces vérifications.

Codes d’erreur

Ces valeurs de code sont stables ; vous pouvez donc créer des branches conditionnelles basées sur celles-ci. La plupart se trouvent aux côtés de detail ; pour la vérification de portefeuille Digital ID, le code correspond à la valeur de error.

Accès et facturation

Requêtes et idempotence

Vérifications bancaires, de téléphone et de risque

Vérification d’entreprise (KYB)

Portefeuilles Digital ID

Rapports et dossiers

Signatures électroniques

Lors de la création de la session, les problèmes liés aux documents ci-dessous sont renvoyés comme valeur du champ concerné avec le statut 400, par exemple {"sign": "signature_document_changed"} :

Webhooks

Réessais et idempotence

Certains échecs peuvent être réessayés en toute sécurité et d’autres non :
  • 429 : attendez l’en-tête Retry-After, puis réessayez.
  • 502 et 503 : réessayez avec une temporisation lorsque la référence de l’endpoint indique que rien n’a été facturé, comme c’est le cas pour les vérifications de téléphone, d’e-mail, bancaires et de risque.
  • 502 sur POST /v3/database-validation/ : lisez d’abord chaque entrée de validation_errors, car ce statut seul ne signifie pas une défaillance temporaire.
  • 503 sur une suppression : répétez la même requête jusqu’à ce qu’elle renvoie 200.
  • Autres 4xx : corrigez d’abord la requête, car la même requête échouera de la même manière.
POST /v3/aml/ et la vérification de portefeuille Digital ID acceptent un en-tête Idempotency-Key contenant jusqu’à 255 caractères. Répéter une requête avec la même clé et le même corps rejoue la réponse stockée, de sorte que le traitement et la facturation n’ont lieu qu’une seule fois. La même clé avec un corps différent répond 409, et tant que la première requête est toujours en cours d’exécution, les endpoints de portefeuille répondent 409 avec un en-tête Retry-After. POST /v3/session/ ne possède pas de clé d’idempotence ; par conséquent, si une requête de création expire, listez vos sessions par vendor_data avant d’en créer une autre.

Voir aussi

Dernière modification le 7 novembre 2026