Passer au contenu principal
Les SDK serveur sont les bibliothèques officielles de Didit pour votre backend. Chacune appelle les endpoints serveur de la référence API avec des requêtes et des réponses typées, vérifie les webhooks que Didit vous envoie et contrôle les tokens de Didit Authentication. Aucune version 1.0.1 ne dispose encore des deux endpoints Google Wallet : démarrer une vérification Google Wallet et soumettre une réponse de portefeuille. Les SDK Python, Node.js, Java, PHP, Ruby et .NET couvrent tous les autres endpoints serveur. Le SDK Go 1.0.1 en omet neuf autres, pour la plupart des endpoints Travel Rule : voir Endpoints absents du SDK Go pour l’instant. Utilisez-les partout où votre code détient une clé API Didit : création de sessions de vérification, lecture des décisions, appel des API autonomes, gestion des utilisateurs, des entreprises, des workflows et des dossiers, filtrage des transactions et des portefeuilles, et Travel Rule. Dans le navigateur ou une application mobile, utilisez plutôt les SDK web et natifs : ils présentent le parcours de vérification à votre utilisateur et ne détiennent jamais votre clé API. Les pages d’endpoints serveur de la référence API, y compris les pages de service Validation en base de données, affichent un exemple de code pour chaque SDK serveur à côté de la requête cURL. Un exemple est affiché dès que la dernière version du SDK contient l’endpoint et chaque champ que l’exemple envoie : un endpoint ou un champ ajouté à l’API obtient ses exemples avec la prochaine version de chaque SDK. Aucune version 1.0.1 ne contient les 16 champs de requête Validation en base de données ajoutés après la génération, comme vin ou bank_account_number. Les pages de service qui les envoient n’affichent donc que le cURL.

​
Installation

​
Configuration

Tous les SDK lisent les mêmes variables d’environnement : un client créé sans option est donc prêt à l’emploi. Les environnements edge n’ont pas d’environnement de processus : dans ce cas, transmettez la clé API au client Node.js sous forme d’option. Tout ce que vous pouvez définir via les variables d’environnement peut aussi être transmis au client, ainsi que l’URL de base, le délai d’expiration, les nouvelles tentatives, les en-têtes par défaut et votre propre client HTTP. Créez un seul client par processus et partagez-le : il gère un pool de connexions et peut être utilisé depuis plusieurs threads ou tâches en même temps. Les méthodes account (inscription programmatique : inscription, connexion, organisations et applications) appellent https://apx.didit.me/auth/v2 et n’envoient jamais votre clé API. Connectez-vous avec account.login, puis transmettez le token d’accès renvoyé au client comme token de compte.

​
Ce que fait chaque SDK

  • Ressources et méthodes. Les appels suivent les ressources de l’API : client.<resource>.<method>(...), par exemple sessions.create, sessions.retrieve_decision ou transactions.create, dans la casse propre à chaque langage. Les identifiants de chemin sont des arguments positionnels ; le corps et les paramètres de requête constituent un seul ensemble de champs nommés. Python, Node.js, PHP et Ruby utilisent les noms de champs de l’API (workflow_id) ; Go, Java et .NET utilisent la casse de leur langage (WorkflowID, workflowId, WorkflowId).
  • Listes. Les méthodes de liste parcourent pour vous l’ensemble des résultats (limit et offset en interne), et exposent aussi chaque page avec count, next, previous et results. En Ruby, auto_paging_each parcourt toutes les pages, et les total_count, next_url et previous_url d’une page correspondent aux count, next et previous de l’API.
  • Fichiers. Les envois (images de documents, selfies, justificatifs de domicile, imports) acceptent un chemin, des octets ou un flux. Les téléchargements (PDF de sessions, rapports) renvoient des octets ou un flux, jamais du JSON analysé.
  • Compatibilité avec les évolutions futures. Un champ de réponse ou une valeur d’énumération que la version du SDK ne connaît pas encore est conservé et lisible ; ce n’est jamais une erreur. Ainsi, un ajout à l’API ne casse pas une intégration déployée.
  • Webhooks. webhooks.verify contrôle les en-têtes X-Signature-V2 et X-Signature ainsi que l’horodatage d’une livraison avec votre secret partagé de webhook, puis renvoie un événement typé. Il accepte une liste de secrets pendant que vous en faites la rotation. Consultez Webhooks pour le schéma de signature.
  • Authentication. Un utilitaire Authentication vérifie les tokens d’accès et d’identité signés par l’émetteur de votre service Authentication, et appelle ses endpoints de token, de session et d’authentification renforcée. Il n’utilise jamais votre clé API.

​
Erreurs, nouvelles tentatives et délais d’attente

Toutes les erreurs dérivent de DiditError. En Go, chaque erreur implémente l’interface didit.Error et est un type pointeur, comme *didit.NotFoundError. Java, PHP et .NET les nomment avec leur suffixe habituel Exception et écrivent API sous la forme Api : DiditException, ApiStatusException, NotFoundException. Les SDK relancent une requête échouée jusqu’à 2 fois, avec un backoff exponentiel à partir de 0,5 seconde (gigue complète, 8 secondes au maximum) et en respectant Retry-After. GET, HEAD, PUT et DELETE sont relancés en cas d’erreur de connexion, de délai dépassé, ainsi que pour les codes 408, 429 et 5xx. POST et PATCH ne sont relancés que pour un 429, ou lorsque la connexion a échoué avant l’envoi de la requête, afin qu’une nouvelle tentative ne crée jamais une seconde session ou transaction. Le délai d’attente par défaut est de 60 secondes. Chaque réponse expose aussi le statut HTTP brut, les en-têtes et l’identifiant de requête. Voir Limite de débit pour les limites associées au 429.

​
Versionnement et support

  • Les SDK suivent le versionnement sémantique, avec une règle pour les modifications de l’API. Une modification qui reflète l’API Didit donne lieu à une version mineure, même si elle peut casser du code typé (un champ dont le type a changé, un champ pouvant désormais valoir null, ou un endpoint, un champ ou une valeur d’énumération supprimé). L’API se comporte déjà ainsi pour tous ses appelants, donc une version plus ancienne du SDK n’est pas plus sûre. Les notes de version répertorient ces modifications sous « Modifications de l’API pouvant casser le code typé ».
  • Une version majeure ne concerne qu’une modification de la conception propre au SDK : une méthode ou une ressource renommée ou supprimée alors que l’API la conserve, une modification de la configuration du client, des erreurs, des nouvelles tentatives, de la pagination ou du comportement de vérification des webhooks, ou l’abandon d’une version de l’environnement d’exécution. Lorsqu’un endpoint quitte l’API ou qu’une méthode est renommée, l’ancienne méthode reste disponible pendant au moins une version mineure supplémentaire, marquée comme obsolète, afin que votre code continue de compiler pendant votre migration vers la nouvelle. Chaque langue conserve son propre numéro de version : Node.js, PHP et Ruby sont en 2.x et les autres en 1.x, car ces trois SDK ont publié une modification de l’API sous forme de version majeure avant l’application de cette règle.
  • Ils sont générés à partir du contrat d’API publié (openapi-25.json et openapi-auth.json), et leurs méthodes Didit Authentication sont vérifiées par rapport à openapi-authentication.json. Les trois fichiers sont contrôlés chaque jour, de sorte qu’un nouvel endpoint ou un nouveau champ arrive dans une version régulière des sept SDK.
  • Chaque SDK prend en charge la version minimale de l’environnement d’exécution indiquée dans le tableau, ainsi que toutes les versions plus récentes. Ses tests s’exécutent sur cette version minimale et sur chaque version plus récente, ou sur chaque version à support long terme pour Node.js et Java.
  • Le fichier CHANGELOG.md de chaque dépôt répertorie les modifications de chaque version.
  • Signalez un problème de sécurité en privé, via les avis de sécurité du dépôt du SDK ou à support@didit.me.
Dernière modification le 7 novembre 2026