Tout ce qui mérite d'être su, rien qui ne le mérite pas.
Commencez par vos identifiants de test
Les identifiants de test fonctionnent sur l'endpoint de production, https://api.broadnet.me, et les messages de test sont envoyés uniquement à votre propre numéro vérifié, vous permettant ainsi de tester la véritable API sans atteindre de clients réels. Confirmez que l'authentification fonctionne et que l'appel de soumission renvoie l'ID de message et le statut attendus. Voir /answers/what-is-sandbox-vs-production et /developers/quickstart.
Vérifiez l'accusé de réception
Une soumission réussie ne signifie pas qu'un message a été distribué. Configurez un webhook pour qu'il pointe vers votre point de terminaison et vérifiez que le DLR (Delivery Request Report) arrive avec un statut de niveau opérateur, afin de vous assurer que la distribution de bout en bout fonctionne. Consultez les pages /answers/what-is-dlr et /answers/what-is-a-messaging-webhook.
Vérifiez l'encodage et les segments
Envoyez un message contenant un emoji ou un caractère non latin pour confirmer que votre pipeline gère correctement l'Unicode et compte les segments ; un bug d'encodage silencieux augmente le coût et peut déclencher les filtres. Consultez /answers/what-is-encoding-gsm-7-ucs-2 et /tools/sms-segment-calculator.
Ensuite, testez de vraies routes.
Vos messages de test prouvent la validité de votre code ; seule une première campagne restreinte vers vos pays de destination réels, après approbation, prouve la qualité de la route. Auditez le flux DLR pour vérifier les codes spécifiques aux opérateurs et la stabilité de la livraison avant de passer à l'échelle. Voir /answers/how-to-choose-sms-provider.