API SMS ou SMPP : quelle connexion choisir ?

Ce guide s'adresse aux ingénieurs et responsables techniques qui doivent choisir comment se connecter à un fournisseur SMS : via une API SMS HTTP/REST, via SMPP, ou les deux. Il explique ce qui distingue réellement les deux approches, sur le réseau comme en exploitation, pour vous permettre de choisir la bonne interface pour chaque type de trafic et de planifier une migration si votre premier choix devient trop étroit.

Pour une vue d'ensemble des modèles d'intégration, webhooks et idempotence compris, consultez notre guide d'intégration d'une API de messagerie.

Quelle est la différence entre une API SMS et SMPP ?

Une API SMS REST envoie chaque message dans une requête HTTPS distincte et renvoie un identifiant de message. SMPP (Short Message Peer-to-Peer) maintient ouverte une session authentifiée de longue durée et y échange, dans les deux sens, des messages binaires appelés PDU. REST privilégie la simplicité ; SMPP privilégie les volumes SMS soutenus.

Comment fonctionne une API SMS REST ?

Vous envoyez un POST HTTPS avec un jeton et un corps JSON, et le fournisseur répond par un identifiant. Chaque requête est indépendante : vous pouvez envoyer depuis n'importe quel serveur, fonction ou conteneur sans gérer de connexion.

Un envoi type avec notre API ressemble à ceci :

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

La réponse est un 200 OK avec l'identifiant du message en texte brut. Le statut final arrive ensuite sur votre webhook : SUBMITTED, SENT, DELIVERED, FAILED ou REJECTED. Les noms de champs et les options figurent dans la référence de l'API SMS.

Les points forts de REST :

• Un outillage familier : n'importe quel langage, n'importe quel client HTTP, des codes de statut standard définis par la RFC 9110.
• Une sécurité simple : TLS partout et un jeton dans l'en-tête Authorization.
• De l'envoi en masse sans connexion : vous chargez un fichier de destinataires en une requête au lieu d'ouvrir une session.
• Une seule API pour plusieurs canaux : le même schéma envoie des modèles WhatsApp ou des cartes RCS.

Les limites de REST : chaque message, ou chaque lot, coûte un aller-retour HTTP, et vous atteindrez une limite de requêtes par seconde bien avant une limite opérateur. Pour la plupart du trafic applicatif, cela ne pose jamais problème.

Comment fonctionne SMPP ?

SMPP est un protocole binaire défini par la spécification SMPP v3.4, publiée par le SMPP Developers Forum (devenu ensuite le SMS Forum) et qui reste la version la plus déployée. Votre système, appelé ESME (External Short Message Entity), se connecte au SMSC (Short Message Service Centre) du fournisseur et ouvre une session appelée bind.

Types de bind

• Transmitter (TX), via bind_transmitter : soumission de messages uniquement.
• Receiver (RX), via bind_receiver : réception des accusés de réception et des messages entrants uniquement.
• Transceiver (TRX), via bind_transceiver : les deux sur une seule session. C'est le choix habituel.

Cycle de vie d'une session

1. Ouvrez une connexion TLS vers l'hôte et le port communiqués par votre fournisseur.
2. Envoyez bind_transceiver avec votre system_id et votre mot de passe, puis attendez une réponse avec command_status à 0.
3. Envoyez les messages avec submit_sm. Chaque submit_sm_resp renvoie un message_id.
4. Recevez les accusés de réception sous forme de deliver_sm et répondez à chacun par deliver_sm_resp.
5. Envoyez régulièrement enquire_link pendant les périodes d'inactivité pour que chaque partie sache que la session est vivante.
6. Fermez avec unbind et attendez unbind_resp.

Chaque PDU porte un numéro de séquence, repris à l'identique dans la réponse : c'est ainsi que vous associez un submit_sm_resp au message envoyé. Notre documentation SMPP détaille chaque étape avec nos paramètres.

Qu'est-ce que le fenêtrage SMPP et pourquoi compte-t-il ?

Le fenêtrage consiste à envoyer plusieurs PDU submit_sm avant d'avoir reçu leurs réponses. Le nombre de PDU non acquittées autorisées en vol constitue la fenêtre. C'est la principale raison pour laquelle SMPP soutient un débit supérieur à un HTTP qui traite une requête à la fois.

Avec une fenêtre de 1, votre client envoie un message, attend un aller-retour complet pour la réponse, puis envoie le suivant. Le débit est alors plafonné par la latence réseau, pas par le débit convenu. Avec une fenêtre plus large, la connexion reste occupée pendant que les réponses arrivent.

Quelques règles empiriques :

• Utilisez la taille de fenêtre convenue avec votre fournisseur et ne la dépassez jamais ; les PDU en excès peuvent être rejetées.
• Respectez le débit convenu par bind. Si vous recevez ESME_RTHROTTLED, ralentissez et réessayez avec un backoff.
• Suivez les numéros de séquence en attente pour qu'une déconnexion ne vous fasse pas perdre la trace des messages acceptés.
• Montez en charge en ajoutant des binds, dans la limite du nombre convenu pour votre compte, plutôt qu'en élargissant sans cesse la fenêtre.

Les limites par défaut de notre API REST et de nos binds SMPP figurent dans errors and limits ; les limites de votre compte sont confirmées lors du provisionnement de l'accès.

En quoi les accusés de réception diffèrent-ils ?

En REST, le fournisseur envoie un événement JSON à votre webhook. En SMPP, l'accusé arrive sous forme de PDU deliver_sm sur la session, avec le bit d'accusé de réception positionné dans esm_class. Les deux sont asynchrones : ni un 200 OK ni un submit_sm_resp ne signifient que le mobile a reçu le message.

La spécification SMPP v3.4 donne le format texte de l'accusé à titre d'exemple et laisse le format exact au fabricant du SMSC, mais la plupart des fournisseurs le suivent :

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

Si vos systèmes consomment les deux interfaces, ramenez les états SMPP à un modèle de statuts unique. Une correspondance type :

Deux différences pratiques comptent davantage que le format :

• L'acquittement. Un client SMPP doit répondre à chaque deliver_sm. Les accusés non acquittés sont renvoyés et peuvent ralentir le bind. Un gestionnaire de webhook doit, pour la même raison, répondre rapidement par un 2xx.
• La reprise. Si votre client SMPP est déconnecté, les accusés attendent le bind suivant ou peuvent expirer dans la file du fournisseur. En REST, un fournisseur peut proposer de renvoyer les accusés sur une plage de dates. Demandez comment chacun fonctionne.

Pour comprendre la signification de chaque statut, lisez les statuts de livraison des messages expliqués.

Comment l'encodage est-il géré ?

Les deux interfaces doivent choisir entre GSM-7 et Unicode, et toutes deux découpent les messages longs en segments. La différence tient à qui fait le travail.

• REST : vous renseignez un champ comme messageType à TEXT ou UNICODE, et la plateforme segmente les messages longs. Notre API propose aussi POST /sms/identify pour compter au préalable les caractères et les segments.
• SMPP : vous renseignez data_coding (0 pour l'alphabet GSM-7 par défaut, 8 pour UCS-2) et encodez vous-même les octets. Pour les messages longs, vous ajoutez soit un User Data Header à chaque partie en positionnant esm_class à 0x40, soit vous envoyez le texte complet dans le champ message_payload si votre fournisseur l'active.

Selon la 3GPP TS 23.040, un SMS unique transporte 140 octets : 160 caractères GSM-7 ou 70 caractères UCS-2, ramenés à 153 ou 67 par partie lorsque l'en-tête est ajouté. Une seule lettre arabe ou un seul emoji fait passer tout le message en Unicode. Les erreurs d'encodage sont le défaut d'intégration SMPP le plus fréquent : testez avec de l'arabe, des emoji et des textes longs. Voir notre guide des limites de caractères.

Comment se comparent les modèles de sécurité ?

REST s'appuie sur TLS et sur un jeton Bearer à chaque requête. SMPP v3.4 n'a pas de chiffrement propre et transmet les identifiants dans le bind : il dépend donc du transport et des contrôles réseau qui l'entourent.

Pour SMPP :

• Utilisez TLS (TLS 1.3 est défini par la RFC 8446) ou une liaison privée ; jamais de SMPP en clair sur l'internet public.
• Enregistrez les adresses IP sources pour que seuls vos serveurs puissent établir un bind.
• Stockez le system_id et le mot de passe comme des secrets, distincts par environnement, et renouvelez-les en cas d'exposition.
• Surveillez les échecs de bind, qui peuvent révéler une erreur de configuration ou un usage abusif des identifiants.

Pour REST :

• Gardez le jeton uniquement côté serveur, jamais dans une application mobile ni dans du code navigateur.
• Évitez les anciennes interfaces HTTP qui passent un identifiant et un mot de passe dans l'URL, où ils finissent dans les journaux.
• Protégez le webhook avec HTTPS, un chemin impossible à deviner et une validation stricte du corps de requête.

Que vous coûte chaque option en exploitation ?

REST n'ajoute quasiment aucune charge d'exploitation : une requête réussit ou renvoie une erreur que vous pouvez réessayer. SMPP ajoute un composant permanent qu'il faut surveiller et maintenir.

Un client SMPP doit gérer :

1. les connexions, avec une reconnexion par backoff et jitter plutôt qu'une boucle serrée ;
2. les keep-alive et la détection des connexions silencieuses à moitié ouvertes ;
3. le contrôle de la fenêtre et du débit par bind ;
4. le suivi des séquences et la réconciliation après déconnexion ;
5. l'acquittement et le stockage des accusés de réception ;
6. la logique d'encodage et de concaténation ;
7. la supervision de l'état des binds, du débit, des erreurs de throttling et du retard des accusés.

Des bibliothèques open source éprouvées gèrent le protocole, mais votre équipe reste responsable du comportement autour, y compris pendant une fenêtre de maintenance du fournisseur à 3 heures du matin.

Quand utiliser chacune ?

Utilisez REST, sauf si vous avez une raison claire d'ajouter SMPP.

Choisissez une API SMS REST si

• vous envoyez des OTP, des alertes, des notifications ou des campagnes depuis des applications ;
• vous avez besoin de WhatsApp, de RCS ou d'autres canaux en plus du SMS ;
• votre plateforme tourne sur des fonctions serverless ou des conteneurs éphémères ;
• votre équipe n'a ni expérience de SMPP ni besoin de l'acquérir.

Choisissez SMPP si

• vous envoyez des volumes SMS élevés et soutenus et avez atteint les limites de REST ;
• vous exploitez déjà une passerelle SMPP ou une plateforme de messagerie ;
• vous êtes agrégateur, opérateur ou revendeur et raccordez le trafic SMS de vos propres clients ;
• vous avez besoin du même protocole avec plusieurs fournisseurs amont.

À quoi ressemble une architecture hybride ?

Beaucoup d'entreprises utilisent les deux sur un même compte : REST pour le trafic multicanal et applicatif, SMPP pour le SMS en masse. Le piège est de se retrouver avec deux modèles de livraison.

• Routez par cas d'usage, pas au hasard : par exemple, OTP et WhatsApp en REST, relevés SMS en masse en SMPP.
• Normalisez les statuts issus des webhooks et des deliver_sm dans une seule table indexée par identifiant de message.
• Appliquez une seule politique d'identifiants d'expéditeur (Sender ID) aux deux, car les enregistrements s'appliquent quelle que soit l'interface.
• Produisez des rapports communs, pour qu'une campagne répartie sur les deux interfaces affiche un résultat unique.

Comment migrer d'une API SMS vers SMPP ?

Avancez progressivement, avec les deux interfaces actives, et mesurez avant de déplacer les volumes.

1. Confirmez le besoin : documentez le volume ou le débit que REST ne couvre pas.
2. Demandez le provisionnement : communiquez les pays de destination, les identifiants d'expéditeur, le débit de pointe attendu et les adresses IP sources.
3. Choisissez une bibliothèque cliente éprouvée dans votre stack et encapsulez-la dans votre propre interface d'envoi.
4. Construisez d'abord la gestion des accusés, alignée sur le même modèle de statuts que vos webhooks.
5. Testez l'encodage : GSM-7, arabe, emoji et messages multi-parties sur de vrais mobiles.
6. Testez les pannes : coupez la connexion en plein envoi, déclenchez le throttling et vérifiez la réconciliation.
7. Faites tourner en parallèle : basculez une petite part d'un type de trafic sur SMPP et comparez livraison et accusés.
8. Déplacez les volumes par paliers, en gardant REST comme voie de repli.

Voici une configuration de bind indicative. L'hôte, le port et les limites sont des valeurs fictives ; les valeurs réelles accompagnent vos identifiants provisionnés.

host:                 <provided with your bind>
port:                 <TLS port provided with your bind>
bind type:            transceiver
system_id:            <your system_id>
password:             <your password>
system_type:          (vide sauf indication contraire)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (identifiant d'expéditeur alphanumérique)
dest_addr_ton/npi:    1 / 1   (numéro international)
registered_delivery:  1       (demander les accusés de réception)
data_coding:          0 (GSM-7) or 8 (UCS-2)
enquire_link:         every 30 seconds while idle
window:               as agreed for your account

Exemple concret : un distributeur régional ajoute SMPP pour ses relevés

« Souq Rafiq » (entreprise fictive), un e-commerçant présent aux Émirats arabes unis, en Égypte et en Jordanie, envoie ses OTP et ses mises à jour de commande via une API REST, et ses modèles WhatsApp via la même API. Les relevés de compte mensuels, envoyés par SMS à toute sa base clients, ont pris une telle ampleur que la tâche REST dure plus longtemps que l'entreprise ne le souhaite.

• Décision : conserver les OTP, les mises à jour de commande et WhatsApp en REST. Basculer les SMS de relevé mensuel sur un bind SMPP transceiver.
• Provisionnement : l'équipe enregistre deux IP sources, confirme les identifiants d'expéditeur par pays et convient du débit et du nombre de binds.
• Développement : un petit service SMPP s'appuie sur une bibliothèque open source, écrit les accusés dans la même table de statuts que le webhook et expose la même interface d'envoi interne que la voie REST.
• Tests : les relevés en arabe sont validés en UCS-2, avec une concaténation correcte sur plusieurs mobiles.
• Déploiement : un premier pays bascule. Après comparaison de la livraison et des délais d'accusés avec la référence REST, les autres pays suivent, REST restant la voie de repli.

Erreurs fréquentes

• Choisir SMPP par prestige. Si REST couvre votre volume, SMPP ne fait qu'ajouter du travail.
• Fonctionner avec une fenêtre de 1, puis reprocher au fournisseur un débit trop faible.
• Ne pas acquitter les deliver_sm, ce qui provoque des renvois d'accusés et du throttling.
• Se reconnecter en boucle serrée après une déconnexion, ce qui peut ressembler à une attaque.
• Mélanger short_message et message_payload dans une même PDU, ce qui provoque des erreurs de longueur.
• Faire passer du SMPP en clair sur internet, en exposant identifiants et contenus.
• Garder deux modèles de statuts dans une architecture hybride, si bien que les rapports divergent.
• Limites : ce guide décrit les pratiques courantes. Tailles de fenêtre, débits, ports TLS et détails des accusés varient selon le fournisseur et le compte ; faites-les confirmer lors du provisionnement.

Comment OmniChannels.ai vous aide

OmniChannels.ai propose les deux. L'API REST à l'adresse https://api.broadnet.me utilise un jeton Bearer et couvre le SMS aux côtés de WhatsApp, RCS, Messenger, Instagram, Telegram, E-mail et Push, avec des statuts de livraison poussés vers votre webhook dans un format unique. Pour le SMS à fort volume, des binds SMPP 3.4 sur TLS sont provisionnés par compte, avec liste blanche d'IP sources, et empruntent les mêmes routes SMS via la connectivité opérateur directe de BroadNet. Les revendeurs et partenaires wholesale peuvent disposer de binds dédiés. Commencez par la documentation SMPP ou le quickstart, ou consultez la présentation développeurs.