SMPP o API HTTP (REST) per gli SMS.
BroadNet offre sia un’API SMS HTTP (REST) sia bind SMPP; la scelta giusta dipende dal volume sostenuto e dal modo in cui vi integrate. Un’API SMS REST è lo strumento giusto per quasi ogni team di ingegneria moderno — è amichevole per il firewall, agnostica al linguaggio e facile da integrare. BroadNet non imposta nessun limite di velocità fisso per account su REST; SMPP è lo strumento giusto quando invii in modo continuativo diverse centinaia di messaggi al secondo o ti servono bind persistenti, o per qualsiasi carico che richieda efficienza binaria e semantica DLR completa. La maggior parte dei clienti di BroadNet inizia con REST e aggiunge un bind SMPP quando il volume lo giustifica.
12 righe. Senza giri di parole.
Stessi criteri, entrambe le colonne. Dove una riga dipende davvero dal caso d’uso, la tabella lo dice. Dove uno dei due è chiaramente lo strumento migliore, la tabella lo dice altrettanto.
| Capacità | colonna a SMS API (REST) HTTPS / JSON | colonna b SMPP Short Message Peer-to-Peer 3.4 / 5.0 |
|---|---|---|
Protocollo | HTTPS POST + JSON | TCP binario, sessione persistente |
Porta predefinita | 443 (TLS) | 2775 (in chiaro); porta TLS fornita con il tuo account |
Autenticazione | Token bearer / chiave API | system_id + password al bind |
Modello di sessione | Richiesta/risposta senza stato | Sessione transceiver vincolata di lunga durata |
Tetto di throughput | Nessun limite di velocità fisso per account; dimensionato in base al tuo traffico | Nessun limite di velocità fisso per account; fino a 30.000 SMS/sec per nodo |
Idempotenza | Nessuna intestazione di idempotenza: conserva l'ID del messaggio restituito e controlla lo stato prima di reinviarlo. | Nessuno nel protocollo: sequence_number associa solo una risposta alla sua richiesta |
Modello di ricevuta di consegna | Callback webhook | deliver_sm sulla stessa sessione |
Controllo della codifica | Automatico (GSM-7 / UCS-2) | Parametro data_coding manuale |
Gestione degli SMS concatenati | Suddivisione automatica | UDH manuale o message_payload |
Gestione del MO in ingresso | Callback webhook | Stessa sessione, deliver_sm |
Sforzo di integrazione | Minuti (curl) a ore | 1-2 settimane (logica di bind, retry, keepalive di sessione) |
Ideale per | App web, prototipi, volume basso-medio | Alto volume sostenuto, aggregatori, telco |
Rivisto trimestralmente · Invia correzioni a press@broadnet.me
bind_transceiverAprire e autenticare la sessionebind_transceiver_respSessione accettatasubmit_smInviare un messaggiosubmit_sm_respAccettato, ID messaggio restituitodeliver_smRicevuta di consegna o messaggio in entratadeliver_sm_respConfermatoenquire_linkKeepalive durante l'inattività
Quale lato si adatta a quale carico di lavoro.
Quando scegliere un’API SMS REST
Scegli REST quando il carico è di volume medio, il team è nativo del web e la tempistica di integrazione è breve. REST è la scelta moderna predefinita per quasi ogni cliente CPaaS nel 2026.
- Volumi di tipo App, in cui l'overhead HTTPS per richiesta non rappresenta il collo di bottiglia.
- Team il cui stack è già nativo HTTP (app web, serverless, backend mobile).
- Carichi dove la facilità di integrazione batte l’efficienza di throughput grezza.
- Orchestrazione multicanale dove l’SMS convive con WhatsApp, RCS ed email.
Quando scegliere SMPP
Scegli SMPP quando entrano in gioco il throughput sostenuto, il controllo totale del DLR o operazioni in stile aggregatore. SMPP è più vecchio e più strano di REST, ma è il protocollo su cui il mondo telco gira davvero, e su scala l’efficienza è reale.
- Invii sostenuti di diverse centinaia di messaggi al secondo, o carichi che richiedono bind persistenti, dove REST inizia a risentire del costo di apertura delle connessioni.
- Carichi che hanno bisogno di controllo totale su data_coding, periodi di validità e message_payload.
- Team che gestiscono MO in ingresso ad alto volume e hanno bisogno di deliver_sm sulla stessa sessione.
- Aggregatori, telco e chiunque gestisca la messaggistica come funzione di business primaria.
Dove si colloca BroadNet.
Posizionamento onesto, non una presentazione di vendita. A volte la risposta giusta è usare l’altro lato di questo confronto — e te lo diremo.
Parla con un esperto di telecomunicazioniOffriamo entrambi, e incoraggiamo i clienti a iniziare dove il loro team è più produttivo. Per la maggior parte dei team nativi del web questo significa REST. Il nostro endpoint POST /sms/sendSms, la specifica OpenAPI 3.1 e l’SDK TypeScript ufficiale coprono il novanta per cento delle esigenze dei clienti senza mai toccare SMPP.
Dove SMPP diventa la risposta giusta è la soglia di volume — diverse centinaia di messaggi al secondo sostenuti — punto in cui l’handshake HTTPS per richiesta inizia a dominare il budget di latenza e il pooling delle connessioni diventa un problema che vale la pena risolvere. A quel punto offriamo un collegamento transceiver SMPP 3.4 crittografato con TLS, senza alcun limite di velocità fisso per account, dimensionato al tuo traffico fino a 30.000 SMS/sec per nodo; host, porta e credenziali vengono forniti con l'accesso di prova.
Supportiamo anche SMPP 5.0 per i clienti che hanno bisogno della semantica message_payload più recente, della gestione del broadcast o del reporting di stato più pulito. In pratica il novantacinque per cento del traffico SMPP telco a livello globale è ancora 3.4, e trattiamo 3.4 come predefinito.
Uno schema comune: REST per il codice a livello applicativo che invia OTP e notifiche individuali, SMPP per il dispatcher di campagne e di massa ad alto volume. Entrambi si collegano allo stesso SMSC, entrambi producono le stesse ricevute, entrambi vengono fatturati sullo stesso listino. I clienti possono mescolare senza pensarci.
Le domande che ci vengono poste più spesso.
Cos’è SMPP esattamente?
+
Cos’è SMPP esattamente?
Short Message Peer-to-Peer Protocol — un protocollo TCP binario progettato alla fine degli anni Novanta per consegnare SMS tra SMSC ed ESME (external short message entities, cioè applicazioni). È il protocollo su cui viaggia davvero la maggior parte del traffico A2P di grado telco tra aggregatori e operatori.
SMPP è più difficile da integrare di REST?
+
SMPP è più difficile da integrare di REST?
Significativamente più difficile. Servono una sessione vincolata di lunga durata, logica di keepalive (enquire_link), gestione dei numeri di sequenza, consapevolezza della codifica e gestione dello stato del bind. La maggior parte dei team usa una libreria SMPP esistente — Cloudhopper per Java, smpp.js per Node, jSMPP per le imprese Java.
Perché i mittenti ad alto volume usano ancora SMPP nel 2026?
+
Perché i mittenti ad alto volume usano ancora SMPP nel 2026?
Efficienza di throughput. Una singola sessione SMPP vincolata può spingere 1.000+ messaggi al secondo per transceiver, mentre REST richiede un nuovo handshake TLS per richiesta a meno di raggruppare accuratamente le connessioni. Per l’alto volume sostenuto, il protocollo binario è significativamente più efficiente.
BroadNet espone SMPP o REST per primo?
+
BroadNet espone SMPP o REST per primo?
Entrambi, con REST come predefinito per le nuove registrazioni e SMPP come conversazione commerciale per carichi che sostengono diverse centinaia di messaggi al secondo o richiedono bind persistenti. Lo stesso SMSC sta dietro entrambi; si applica la stessa semantica DLR.
E SMPP 5.0?
+
E SMPP 5.0?
Lo supportiamo. In pratica la grande maggioranza del traffico A2P su SMPP a livello globale usa ancora 3.4, e trattiamo 3.4 come predefinito per i nuovi collegamenti a meno che un cliente non chieda specificamente 5.0.
Posso usare sia REST sia SMPP dallo stesso account?
+
Posso usare sia REST sia SMPP dallo stesso account?
Sì, contro lo stesso SMSC. La maggior parte dei clienti enterprise fa esattamente questo — REST per il codice a livello applicativo e SMPP per il dispatcher ad alto volume.
Come vengono gestite diversamente le ricevute di consegna?
+
Come vengono gestite diversamente le ricevute di consegna?
REST riceve un callback webhook all’URL che hai registrato. SMPP riceve frame deliver_sm sulla stessa sessione che ha inviato il messaggio. Entrambi portano gli stessi campi DLR e lo stesso payload di ricevuta al livello BroadNet.
La scelta di REST al posto di SMPP comporta una perdita di deliverability?
+
La scelta di REST al posto di SMPP comporta una perdita di deliverability?
No. Lo stesso messaggio passa attraverso lo stesso SMSC e lo stesso percorso dell'operatore dietro entrambi gli endpoint: la fedeltà DLR e il routing sono identici. La scelta è puramente operativa, non un compromesso in termini di deliverability.
Letture correlate.
Tutti i confrontiAltri confronti.
Parla con un esperto di telecomunicazioni.
Raccontaci il carico di lavoro, i mercati e i volumi. Ti diremo onestamente se BroadNet è la scelta giusta, quella sbagliata o parte di un’architettura a livelli con una delle alternative.