Pour intégrer un OTP WhatsApp au Maroc, configurez le compte expéditeur, vérifiez le modèle d’authentification et reliez votre backend aux opérations d’émission et de vérification. L’application doit ensuite contrôler le résultat de vérification avant de valider la connexion ou l’action concernée. Le temps de mise en service dépend de ces prérequis.
Préparer le compte et le contrat API
La référence WASEL Templates et OTP décrit les opérations disponibles et les prérequis. Préparez une configuration WhatsApp active, une clé externe avec le bon périmètre et un scénario de test interne. Confirmez la langue et le statut du template avant l’envoi.
Utilisez les endpoints, le mécanisme d’authentification et les champs fournis pour votre espace. Le document OpenAPI du site vitrine concerne les formulaires de contact et de téléchargement ; il ne documente pas le produit OTP.
Exemple de requête HTTP à adapter au contrat de votre espace
# URL et en-tête à renseigner côté serveur depuis votre documentation.: "${WASEL_OTP_SEND_URL:?Renseignez l’URL documentée}": "${WASEL_AUTH_HEADER:?Renseignez l’en-tête documenté}"
curl --fail-with-body --request POST "$WASEL_OTP_SEND_URL" \ --header "$WASEL_AUTH_HEADER" \ --header 'Content-Type: application/json' \ --data @otp-send.jsonLe fichier otp-send.json doit reprendre le corps de requête réel de votre espace : destinataire, langue et paramètres attendus. Ce modèle HTTP ne publie pas un endpoint ou un SDK WASEL supposé. Conservez les clés sur le serveur.
Organiser le cycle du code
| Étape | Action | Contrôle |
|---|---|---|
| Demande | L’utilisateur commence une connexion ou une validation | Associer la demande au bon parcours |
| Émission | Le serveur appelle l’opération OTP | Conserver la référence utile au suivi |
| Réception | Le client reçoit le message si la livraison réussit | Distinguer acceptation, livraison et vérification |
| Vérification | Le serveur soumet le code reçu | Attendre un résultat de vérification positif |
| Relance | Un nouveau code est demandé selon la politique retenue | Vérifier le traitement du code précédent et les limites |
| Reprise | L’utilisateur rencontre un échec | Proposer un chemin de support sans contourner la vérification |
Paramètres à confirmer
La référence opérationnelle décrit ttl_minutes pour la validité, max_attempts pour les essais, button_type pour l’affichage et reference pour le contexte métier. Les valeurs autorisées et le format de requête doivent être lus dans le contrat actuel.
Une référence explicite aide à distinguer deux actions simultanées. Ne supposez pas qu’un code demandé dans un onglet doit valider toutes les sessions ouvertes.
Sept tests avant la mise en production
- Code correct et encore valide.
- Code erroné.
- Code expiré.
- Nombre maximal de tentatives atteint.
- Nouveau code émis puis tentative avec l’ancien code.
- Code présenté avec une autre référence.
- Livraison impossible puis reprise du parcours.
Les résultats documentés comprennent verified, invalid_code, expired, max_attempts_exceeded et not_found. Traitez-les selon la réponse réelle de l’API et ne journalisez pas les codes en clair.
Chiffrer le pilote
Comptez les envois, les relances et les vérifications terminées. Séparez les frais Meta, l’abonnement WASEL et les services additionnels. La méthode de calcul du prix WhatsApp API et le comparatif des critères OTP vous aident à préparer ce budget sans taux de livraison ou économie supposés.
Questions fréquentes
Peut-on intégrer un OTP WhatsApp en 30 minutes ?
La durée dépend de la configuration du compte, des templates et du contrat API disponible. Préparez les prérequis et un pilote ; aucun délai universel de mise en service n’est garanti.
Quels paramètres faut-il vérifier ?
La documentation WASEL décrit notamment ttl_minutes, max_attempts, button_type et reference. Vérifiez les champs et les valeurs autorisées dans le contrat API de votre espace.
Sources et suite
Consultez les messages d’authentification WhatsApp pour le rôle de la catégorie, puis préparez votre premier test avec la page API développeurs.