Le test webhook Twilio en local permet de recevoir réponses SMS, callbacks voix et mises à jour de statut messaging sur votre machine. Twilio envoie des POST form-encoded — votre localhost a besoin d'une URL HTTPS publique pendant le développement.
Pourquoi Twilio exige une URL publique
Quand un utilisateur envoie un SMS ou termine un appel, Twilio POST les données vers votre webhook configuré. http://localhost:3000/sms est injoignable. Un tunnel localhost fournit l'endpoint HTTPS nécessaire.
Types de webhooks Twilio à tester
- SMS entrant : message texte reçu sur votre numéro.
- Callbacks statut SMS : sent, delivered, failed.
- Callbacks voix : requêtes TwiML à la connexion.
- WhatsApp : webhooks inbound et statut Business API.
- Conversations API : messages et participants.
Étapes : test webhook Twilio
- Lancez votre app avec routes Twilio (
/sms/inbound). - Exécutez
npx portpreview 3000. - Console Twilio : URL webhook = URL tunnel + chemin.
- Méthode POST, content-type correspondant au handler.
- Envoyez un SMS test et inspectez la requête capturée.
- Validez
X-Twilio-Signatureet retournez TwiML ou 2xx.
Valider les signatures Twilio en local
Twilio signe chaque requête avec l'URL complète et les paramètres POST via votre auth token. Utilisez l'URL tunnel exacte (pas localhost) pour la validation. Rejetez les signatures invalides même en dev.
Conseils debug Twilio
Form-encoded : pas du JSON — parsez application/x-www-form-urlencoded.
TwiML : handlers voix/SMS doivent retourner du XML TwiML valide.
Timeout : réponse en 15s max — utilisez le rejeu webhook pour tester les retries.
Twilio CLI vs tunnel localhost
Le CLI Twilio simule des requêtes inbound. Un tunnel avec capture offre visibilité persistante, rejeu et workflow multi-providers. Guide général : déboguer les webhooks en local.
Combinez avec les guides Stripe et GitHub pour des workflows messaging complets. Rejoignez la waitlist PortPreview.