Comment intégrer Didit : API, SDK et liens sans code
Vous n'avez pas besoin d'écrire de code pour commencer à vérifier des personnes avec Didit - utilisez un lien sans code, ou faites appel à un SDK ou à l'API lorsque vous voulez de l'automatisation.
Trois voies. Les liens sans code ne nécessitent aucun backend. L'API avec une redirection est l'intégration standard. Les SDK intègrent le flux dans votre propre application, et sont la seule voie qui prend en charge le NFC. Quelle que soit votre choix, récupérez les résultats avec les webhooks.
Vous n'avez pas besoin d'un développeur pour lancer la vérification d'identité avec Didit. Il existe une option sans code qui prend quelques minutes, ainsi que des options API et SDK pour quand vous voulez l'automatiser dans votre propre produit.
#Puis-je utiliser Didit sans coder ?
Oui. Une fois que vous avez construit un workflow dans la console, vous pouvez générer une session de vérification de deux façons, sans aucun code :
- L'étape une émet la clé API avec laquelle votre backend s'authentifie.
- L'étape deux choisit le workflow que chaque session exécutera.
- L'étape trois enregistre où les résultats sont envoyés, et déclenche un envoi de test.
- L'étape quatre, c'est le code : copiez le guide de démarrage rapide pour votre stack.
- Lien de vérification (à usage unique)
Depuis la page Workflows, créez une session directement dans la console. Vous obtenez une URL unique et un code QR pour cette personne : envoyez-le par e-mail, par SMS, ou par n'importe quel canal, ou faites-le scanner en personne.
- Lien réutilisable (Unilink)
Chaque workflow dispose également d'un lien réutilisable qui démarre une nouvelle session à chaque visite. Placez-le derrière un bouton sur votre site, imprimez-le sous forme de code QR pour un kiosque ou une agence, ou partagez-le avec des affiliés. Voir liens réutilisables.
Les deux options contournent entièrement l'API et votre backend : le bon choix pour un MVP, une revue manuelle, une vérification en personne, ou pour démarrer avant d'avoir construit quoi que ce soit sur mesure.
#Quand vous voulez de l'automatisation
Si vous avez besoin que le résultat mette à jour vos propres systèmes automatiquement, pas seulement qu'il apparaisse dans la console, alors l'API ou un SDK sont ce qu'il vous faut :
| Vous voulez... | Utilisez |
|---|---|
| Rediriger les utilisateurs vers une page de vérification hébergée depuis votre application | Un seul appel API pour créer une session, puis une redirection vers l'URL renvoyée |
| Intégrer la vérification dans votre application web | Le SDK JavaScript ou l'iframe in-context |
| Vérifier dans une application native iOS, Android, Flutter ou React Native | Le SDK natif correspondant, requis pour le NFC |
| Ajouter la vérification à WordPress/WooCommerce ou Shopify | Le plugin WordPress/WooCommerce ou Shopify, sans code requis |
| L'intégrer dans un outil d'automatisation | L'API depuis Zapier, n8n, ou tout outil capable d'effectuer une requête HTTP et de recevoir un webhook |
| Obtenir les résultats envoyés à votre backend dès qu'ils sont prêts | Webhooks |
| Exécuter vous-même des contrôles individuels (traitement par lots, interface de capture personnalisée) | Les API autonomes, appelées directement plutôt que via une session de workflow |
#Envoyer le lien vous-même
Si vous créez une session via l'API, Didit renvoie l'URL de vérification, et il vous revient ensuite de la transmettre. L'envoyer depuis votre propre produit, avec votre propre texte et votre propre image de marque, est généralement de toute façon la meilleure expérience : la personne vous fait déjà confiance, et un message d'un expéditeur inconnu représente un coût de conversion.
Si vous avez besoin que Didit envoie l'e-mail à la personne à votre place, transmettez les coordonnées lors de la création de la session. Vérifiez ce qui est pris en charge pour votre configuration plutôt que de le supposer, et notez que la langue de l'e-mail est un champ distinct de la langue du flux. Voir définir la langue de vérification.
#Choisir entre hébergé, intégré et natif
| Redirection hébergée | Intégré (SDK web / iframe) | SDK natif | |
|---|---|---|---|
| Code requis | Minimal | Modéré | Maximal |
| L'utilisateur quitte votre application | Oui | Non | Non |
| Lecture de puce NFC | Non | Non | Oui |
| Meilleur comportement caméra | Bon | Bon | Meilleur |
| Le domaine personnalisé retire Didit de l'URL | Oui | n/a | n/a |
Si le NFC compte pour vous, cette ligne tranche : la puce ne peut pas être lue depuis une page de navigateur. Voir vérification par puce NFC.
Il est utile de confirmer avec votre contact Didit quelles options intégrées sont disponibles sur votre offre avant de définir le périmètre d'un projet autour de l'une d'elles.
#API autonomes contre sessions de workflow
Une session de workflow exécute les contrôles ensemble, produit une décision agrégée unique, et s'appuie sur les allocations gratuites par fonctionnalité pour les quatre fonctionnalités du palier gratuit. Un appel API autonome exécute un seul contrôle sur des données que vous fournissez, renvoie uniquement ce résultat, et est facturé par appel, sans allocation gratuite.
Les appels autonomes sont l'outil adapté pour le traitement par lots, pour une interface de capture que vous avez construite vous-même, ou pour un contrôle que vous voulez exécuter en dehors d'un flux d'intégration. Ce n'est pas le bon outil si vous vouliez profiter du palier gratuit.
#Tester avant la mise en production
Créez une application distincte en mode sandbox pour les tests : chaque application a sa propre clé API et ses propres workflows, donc le trafic de test ne touche jamais les données en production, et les sessions sandbox ne coûtent rien tout en vous permettant de forcer n'importe quel résultat. Voir tester en sandbox.
#Prochaines étapes
- Configurez d'abord un workflow si ce n'est pas déjà fait : construire un workflow de vérification
- Récupérez les résultats dès qu'ils sont prêts : obtenir les résultats de vérification avec les webhooks
- Où trouver votre clé API : gérer vos clés API
- Quand quelque chose renvoie une erreur : les erreurs API et leur signification