SMPP ou API HTTP (REST) pour les SMS.
BroadNet propose à la fois une API SMS HTTP (REST) et des binds SMPP ; le bon choix dépend de votre volume soutenu et de votre mode d’intégration. Une API SMS REST est le bon outil pour presque toute équipe d’ingénierie moderne — elle est compatible pare-feu, agnostique au langage et facile à intégrer. BroadNet n'impose aucune limite de débit fixe par compte sur REST ; SMPP est le bon outil lorsque vous envoyez en continu plusieurs centaines de messages par seconde ou avez besoin de liaisons persistantes, ou pour toute charge nécessitant une efficacité binaire et une sémantique DLR complète. La plupart des clients de BroadNet commencent en REST et ajoutent une liaison SMPP quand leur volume le justifie.
12 lignes. Sans détour.
Mêmes critères, deux colonnes. Là où une ligne dépend réellement du cas d’usage, le tableau le dit. Là où l’un des deux est clairement le meilleur outil, le tableau le dit aussi.
| Capacité | colonne a SMS API (REST) HTTPS / JSON | colonne b SMPP Short Message Peer-to-Peer 3.4 / 5.0 |
|---|---|---|
Protocole | HTTPS POST + JSON | TCP binaire, session persistante |
Port par défaut | 443 (TLS) | 2775 (en clair) ; port TLS fourni avec votre compte |
Authentification | Jeton bearer / clé d’API | system_id + mot de passe au bind |
Modèle de session | Requête/réponse sans état | Session transceiver liée de longue durée |
Plafond de débit | Aucune limite de débit fixe par compte ; dimensionné selon votre trafic | Aucune limite de débit fixe par compte ; jusqu’à 30 000 SMS/seconde par nœud |
Idempotence | Absence d'en-tête d'idempotence : conservez l'identifiant du message renvoyé et vérifiez son statut avant de le renvoyer | Rien dans le protocole : sequence_number associe seulement une réponse à sa requête |
Modèle d’accusé de réception | Callback de webhook | deliver_sm sur la même session |
Contrôle de l’encodage | Automatique (GSM-7 / UCS-2) | Paramètre data_coding manuel |
Gestion des SMS concaténés | Découpage automatique | UDH manuel ou message_payload |
Gestion du MO entrant | Callback de webhook | Même session, deliver_sm |
Effort d’intégration | Minutes (curl) à heures | 1 à 2 semaines (logique de bind, réessais, keepalive de session) |
Idéal pour | Applis web, prototypes, volume faible à moyen | Fort volume soutenu, agrégateurs, télécoms |
Révisé chaque trimestre · Envoyez vos corrections à press@broadnet.me
bind_transceiverOuvrir et authentifier la sessionbind_transceiver_respSession acceptéesubmit_smEnvoyer un messagesubmit_sm_respAccepté, ID du message renvoyédeliver_smAccusé de réception ou message entrantdeliver_sm_respConfirméenquire_linkKeepalive en cas d'inactivité
Quel camp convient à quelle charge de travail.
Quand choisir une API SMS REST
Choisissez REST quand la charge est de volume intermédiaire, que l’équipe est native du web et que le délai d’intégration est court. REST est le choix moderne par défaut pour presque tout client CPaaS en 2026.
- Volumes de type application, où le surcoût HTTPS par requête n'est pas le goulot d'étranglement.
- Équipes dont la pile est déjà native HTTP (applis web, serverless, back-ends mobiles).
- Charges où la facilité d’intégration l’emporte sur l’efficacité de débit brute.
- Orchestration multicanale où le SMS côtoie WhatsApp, RCS et l’e-mail.
Quand choisir SMPP
Choisissez SMPP quand le débit soutenu, le contrôle total du DLR ou des opérations de style agrégateur entrent en jeu. SMPP est plus ancien et plus étrange que REST, mais c’est le protocole sur lequel tourne réellement le monde des télécoms, et à l’échelle l’efficacité est réelle.
- Envois soutenus de plusieurs centaines de messages par seconde, ou charges nécessitant des liaisons persistantes, là où REST commence à ressentir le coût d’établissement des connexions.
- Charges nécessitant un contrôle total sur data_coding, les périodes de validité et message_payload.
- Équipes qui exploitent du MO entrant à fort volume et ont besoin de deliver_sm sur la même session.
- Agrégateurs, télécoms et quiconque exploite la messagerie comme fonction métier principale.
Où se situe BroadNet.
Un positionnement honnête, pas un argumentaire. Parfois la bonne réponse est d’utiliser l’autre camp de cette comparaison — nous vous le dirons.
Parler à un expert télécomNous proposons les deux, et encourageons les clients à commencer là où leur équipe est la plus productive. Pour la plupart des équipes natives du web, cela signifie REST. Notre point d’accès POST /sms/sendSms, la spécification OpenAPI 3.1 et le SDK TypeScript officiel couvrent quatre-vingt-dix pour cent des besoins clients sans jamais toucher à SMPP.
Là où SMPP devient la bonne réponse, c’est au seuil de volume — plusieurs centaines de messages par seconde soutenus — moment où le handshake HTTPS par requête commence à dominer le budget de latence et où la mise en pool des connexions devient un problème qui vaut la peine d’être résolu. À ce stade, nous proposons une liaison émetteur-récepteur SMPP 3.4 chiffrée TLS sans limite de débit fixe par compte, dimensionnée selon votre trafic jusqu'à 30 000 SMS/seconde par nœud ; l’hôte, le port et les identifiants sont fournis avec votre accès de test.
Nous prenons aussi en charge SMPP 5.0 pour les clients qui ont besoin de la sémantique message_payload plus récente, de la gestion de diffusion ou du reporting de statut plus propre. En pratique, quatre-vingt-quinze pour cent du trafic SMPP télécom dans le monde reste en 3.4, et nous traitons 3.4 comme le défaut.
Un schéma courant : REST pour le code de couche applicative qui envoie des OTP et notifications individuels, SMPP pour le répartiteur de campagnes et de masse à fort volume. Les deux se lient au même SMSC, les deux produisent les mêmes accusés de réception, les deux sont facturés sur la même grille tarifaire. Les clients peuvent mélanger sans y penser.
Les questions qu’on nous pose le plus souvent.
Qu’est-ce que SMPP exactement ?
+
Qu’est-ce que SMPP exactement ?
Short Message Peer-to-Peer Protocol — un protocole TCP binaire conçu à la fin des années 1990 pour livrer des SMS entre SMSC et ESME (external short message entities, c’est-à-dire des applications). C’est le protocole sur lequel circule réellement la majeure partie du trafic A2P de qualité télécom entre agrégateurs et opérateurs.
SMPP est-il plus difficile à intégrer que REST ?
+
SMPP est-il plus difficile à intégrer que REST ?
Nettement plus difficile. Il vous faut une session liée de longue durée, une logique de keepalive (enquire_link), la gestion des numéros de séquence, une conscience de l’encodage et la gestion de l’état du bind. La plupart des équipes utilisent une bibliothèque SMPP existante — Cloudhopper pour Java, smpp.js pour Node, jSMPP pour les entreprises Java.
Pourquoi les expéditeurs à fort volume utilisent-ils encore SMPP en 2026 ?
+
Pourquoi les expéditeurs à fort volume utilisent-ils encore SMPP en 2026 ?
L’efficacité de débit. Une seule session SMPP liée peut pousser 1 000+ messages par seconde par transceiver, là où REST exige un nouveau handshake TLS par requête à moins de mettre soigneusement en pool les connexions. Pour le fort volume soutenu, le protocole binaire est nettement plus efficace.
BroadNet expose-t-il SMPP ou REST en premier ?
+
BroadNet expose-t-il SMPP ou REST en premier ?
Les deux, avec REST par défaut pour les nouvelles inscriptions et SMPP comme discussion commerciale pour les charges qui soutiennent plusieurs centaines de messages par seconde ou nécessitent des liaisons persistantes. Le même SMSC est derrière les deux ; la même sémantique DLR s’applique.
Et SMPP 5.0 ?
+
Et SMPP 5.0 ?
Nous le prenons en charge. En pratique, la grande majorité du trafic A2P en SMPP dans le monde utilise encore 3.4, et nous traitons 3.4 comme le défaut pour les nouveaux liens sauf si un client demande spécifiquement 5.0.
Puis-je utiliser à la fois REST et SMPP depuis le même compte ?
+
Puis-je utiliser à la fois REST et SMPP depuis le même compte ?
Oui, sur le même SMSC. La plupart des clients grands comptes font exactement cela — REST pour le code de couche applicative et SMPP pour le répartiteur à fort volume.
Comment les accusés de réception sont-ils gérés différemment ?
+
Comment les accusés de réception sont-ils gérés différemment ?
REST reçoit un callback de webhook à l’URL que vous avez enregistrée. SMPP reçoit des trames deliver_sm sur la même session que celle qui a soumis le message. Les deux portent les mêmes champs DLR et la même charge d’accusé de réception à la couche BroadNet.
Est-ce que je perds en termes de délivrabilité en choisissant REST plutôt que SMPP ?
+
Est-ce que je perds en termes de délivrabilité en choisissant REST plutôt que SMPP ?
Non. Le même message transite par le même SMSC et le même opérateur pour les deux points de terminaison ; la fidélité DLR et le routage sont identiques. Le choix est purement opérationnel et n’implique aucun compromis en matière de délivrabilité.
À lire aussi.
Toutes les comparaisonsAutres comparaisons.
Parlez à un expert télécom.
Dites-nous la charge de travail, les marchés et les volumes. Nous vous dirons honnêtement si BroadNet est le bon choix, le mauvais choix, ou un maillon d’une architecture en couches avec l’une des alternatives.