API de vérification d'âge pour sites et applications

Première étape, vérifier le numéro. Vous appelez POST /start-verification avec flow=age et affichez le lien profond WhatsApp renvoyé, sous forme de QR code sur ordinateur ou de bouton sur mobile. Le visiteur envoie un message pré-rempli depuis son propre compte WhatsApp : le contrôle du numéro est prouvé par l'acte d'envoi, et non par un code que vous lui auriez expédié.

Deuxième étape, fixer le seuil. Le même appel accepte un min_age facultatif. Sans lui, c'est le seuil configuré sur votre compte qui s'applique, soit 18 tant que vous ne l'avez pas changé. min_age n'est accepté que sur flow=age et doit être un entier positif ; tout le reste renvoie un 400.

Troisième étape, passer le contrôle d'âge. Dès que la moitié téléphone est prouvée, la réponse contient un bloc age avec status pending et une age_verification_url. Le visiteur reçoit ce même lien à usage unique sur WhatsApp, et vous pouvez l'utiliser pour le faire avancer dans le navigateur où il se trouve déjà. Il répond chez le prestataire d'âge, puis revient sur votre callback_url avec token et age=verified, denied ou failed ajoutés.

Quatrième étape, recevoir le résultat. Un second webhook, age_verification_result, part dès que le prestataire a répondu, et GET /check-verification-status renvoie la même chose. Le bloc age porte status, verified, required — le seuil réellement contrôlé —, verified_at et provider.

Un piège mérite d'être connu avant d'écrire la boucle de polling. Le statut de la session elle-même passe à verified dès que le numéro est prouvé, alors que age.status vaut encore pending. Prenez le bloc age comme signal de l'étape d'âge, jamais le statut de la session.

Les deux étapes répondent à deux questions différentes, et le flux les garde séparées à dessein. Envoyer un message WhatsApp prouve que le visiteur contrôle ce numéro. Cela ne dit strictement rien de son âge : un numéro de téléphone n'est pas une preuve d'âge, et aucune partie de ce flux ne le traite comme telle.

Ce que l'étape téléphone vous apporte, c'est un endroit où poser la réponse. Un résultat d'âge isolé est un fait sans attache — quelqu'un, quelque part, a franchi un seuil. Lié à un numéro que le visiteur vient d'utiliser de façon démontrable, il devient quelque chose que vous saurez reconnaître à la visite suivante.

Cela rend aussi le visiteur récurrent peu coûteux. Un résultat positif est conservé pendant un an en regard du numéro : quelqu'un qui a déjà franchi le même seuil reprouve son numéro et reporte la réponse précédente au lieu d'être renvoyé chez le prestataire. Terminer le message WhatsApp par #reset ignore ce cache quand il vous faut une réponse fraîche.

La question que pose un contrôle d'âge est un booléen. La plupart des données habituellement collectées pour y répondre ne le sont pas, et c'est ce qui rend l'archive de documents si mauvaise en rapport coût-bénéfice : vous finissez par détenir des passeports et des permis de conduire pour stocker un oui.

Ce dont votre application a besoin tient en peu de chose. Le résultat — verified, denied, failed, ou encore pending. Le seuil contrôlé. La date de la réponse, et le prestataire qui l'a donnée. L'identifiant de session et le numéro vérifié qui rattachent la réponse au visiteur en face de vous. C'est tout le bloc age, plus ce que le flux téléphone renvoie déjà.

Ce dont votre application n'a pas besoin, c'est d'une date de naissance ou d'une pièce d'identité, et l'API ne renvoie ni l'une ni l'autre : il n'y a donc aucun champ à journaliser par accident. Une réponse positive est conservée en regard du numéro sous la forme de la réponse, du seuil et de la date. Les identifiants du prestataire vivent dans des secrets côté serveur, et ce que le prestataire a dû regarder pour décider ne vous est pas transmis.

Rien de tout cela ne dit quoi que ce soit de vos propres obligations. Ce que vous devez contrôler, pendant combien de temps vous devez pouvoir en rendre compte et ce qui compte comme méthode acceptable sont des questions pour votre conseil juridique et votre régulateur, pas pour un fournisseur d'API.

La vérification d'âge répond à une question : ce visiteur atteint-il le seuil d'âge que vous avez fixé ? La vérification d'identité en pose une autre : qui est cette personne ? Les deux sont souvent vendues ensemble, et elles déplacent des quantités de données très différentes.

flow=age relève de la première. Il ne renvoie ni nom, ni date de naissance, ni rien issu d'un document. Ce n'est pas du KYC, et un résultat positif n'est pas une affirmation d'identité sur laquelle vous appuyer ailleurs. Si votre obligation est de savoir qui est un client, ce n'est pas l'outil pour cette partie-là.

Il hérite aussi de l'hypothèse qui sous-tend tout contrôle par téléphone : que le numéro appartient à la personne qui s'en sert. Prouver le contrôle en envoyant un message est un terrain plus solide que recevoir un SMS, mais un adolescent qui a accès au téléphone d'un adulte reste un scénario qu'aucun contrôle à distance ne referme complètement. L'article sur les contrôles d'âge qui ne deviennent pas une base de pièces d'identité, en lien ci-dessous, détaille l'architecture, les quatre états et les limites.