À propos de cette vidéo

Les réponses de cette vidéo sont de vraies réponses d'API. Les clés d'API nécessitent un compte payant.

Transcription de la vidéo

1. 00:00Contrôler sur le serveur

   Contrôlez l'adresse sur votre serveur à l'envoi du formulaire d'inscription, et refusez celles qui ne peuvent pas recevoir de courrier. À l'envoi du formulaire, votre serveur envoie l'adresse à /verify/single, lit le statut et décide. Le navigateur ne parle jamais à l'API. Voici une règle simple. Rejetez invalide, car cette boîte n'existe pas. Rejetez jetable, car c'est une boîte à usage unique. Laissez passer rôle, catch-all et inconnu. Ils peuvent appartenir à de vraies personnes. Pourquoi le serveur ? Une clé dans le code du navigateur est livrée à chaque visiteur, et n'importe qui pourrait dépenser vos crédits avec. Les clés viennent avec un compte payant : gardez la vôtre privée.

2. 00:41Next.js

   Dans Next.js, placez le contrôle dans un route handler. Il lit la clé dans l'environnement du serveur, envoie l'e-mail et renvoie un 422 avec un message quand le statut est invalid ou disposable. Regardez le piège. Si l'appel échoue ou expire, status est vide, et ce code laisse passer l'inscription. C'est un choix fait dans cet exemple. Si vous préférez bloquer, renvoyez plutôt une erreur à cet endroit.

3. 01:04React

   React s'exécute dans le navigateur : il ne détient donc jamais la clé. Le formulaire envoie vers votre propre route et affiche le message quand un 422 revient. Dans Django, appelez le SDK Python depuis clean_email sur votre formulaire. Levez une erreur de validation pour invalid ou disposable, et Django l'affiche à côté du champ.

4. 01:21Laravel

   Dans Laravel, écrivez une règle de validation. Le client HTTP envoie l'adresse avec la clé de votre configuration, et la règle échoue pour les deux mêmes statuts. Une erreur de connexion fait simplement un return : le formulaire passe donc quand même.

5. 01:34Go

   En Go, la bibliothèque standard suffit. Ce handler appelle l'API, journalise le résultat et répond 422 pour invalid ou disposable. Lançons-le. Quatre inscriptions entrent. Les adresses support et Leo reçoivent un message de bienvenue. L'adresse Gmail inventée et celle de Mailinator reçoivent le message 422. Le journal du serveur montre pourquoi : role, catch-all, invalid et disposable. Et chaque ligne indique credits_used zéro. Nous avions contrôlé ces quatre adresses sur ce compte plus tôt dans la journée. Si la même adresse revient dans les 24 heures, vous n'êtes pas facturé deux fois. Un utilisateur qui corrige une faute dans le champ du mot de passe et renvoie le formulaire ne coûte rien de plus.

6. 02:15Étapes suivantes

   Les cinq utilisent un seul endpoint. Les champs et les statuts sont documentés sur billionverify.com/docs. 20 crédits gratuits chaque jour où vous utilisez votre compte, jusqu'à 600 par mois. Aucune carte bancaire requise. Commencez sur billionverify.com.

Présenté dans cette vidéo

• Vérification Email à l'Inscription : Guide UX
• Pourquoi la vérification des emails d'inscription des utilisateurs est importante en 2026