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 decode 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êteRetry-After, puis réessayez.502et503: 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.502surPOST /v3/database-validation/: lisez d’abord chaque entrée devalidation_errors, car ce statut seul ne signifie pas une défaillance temporaire.503sur une suppression : répétez la même requête jusqu’à ce qu’elle renvoie200.- 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
- Limite de débit : limites, en-têtes et corps de la réponse
429. - Authentification API : comment envoyer votre clé.
- Tests en sandbox : reproduisez les résultats sans données réelles ni facturation.
- Webhooks : livraison, réessais et ordre.