API SMS per invii verso l’Italia
La chiamata di invio è la parte semplice. Un’integrazione SMS si giudica su quello che torna indietro: ricevute di consegna, messaggi in entrata e il modo in cui gli errori di rete arrivano fino all’applicazione.
Per l’Italia due vincoli non si risolvono lato codice: l’iscrizione dell’alias al Registro AGCOM e la fascia oraria vietata. Entrambi vanno gestiti nella pianificazione, non in un parametro della richiesta.
Ricevute: la parte che serve davvero
Un invio accettato dall’API non è un messaggio consegnato. Lo stato reale arriva dopo, via webhook. Senza la gestione di questi stati l’applicazione non distingue un numero inesistente da un telefono spento.
L’errore ricorrente è considerare uno stato consegnato come prova di lettura. A seconda delle reti la ricevuta può essere emessa all’ingresso nella rete dell’operatore e non alla consegna sul terminale: una statistica costruita su quell’ipotesi sbaglia sempre nella direzione più lusinghiera.
La fascia oraria va gestita nella coda
Il divieto tra le 22:00 e le 08:00 e la domenica si applica al traffico promozionale qualunque sia il canale di invio. Una coda che si svuota di notte invierà messaggi nella fascia vietata.
La pianificazione va quindi fatta in ora italiana e per tipo di traffico. Separare le code transazionali da quelle promozionali risolve entrambi i problemi: i messaggi attesi partono sempre, quelli promozionali solo quando è consentito.
Alias e codifica
L’alias alfanumerico va iscritto al Registro AGCOM prima dell’uso. Nell’integrazione conviene trattarlo come configurazione con ciclo di vita proprio, non come stringa libera per richiesta, altrimenti un valore non registrato produce blocchi silenziosi.
Sul contenuto, un carattere fuori dall’alfabeto GSM a 7 bit porta il messaggio in UCS-2 e riduce il segmento a 70 caratteri. Un’API che non restituisce il numero di segmenti prima dell’invio lascia ripetere l’errore a ogni campagna.
Fonti, per argomento
| Codice paese mobile | www.twilio.com2026-09-22 |
| Mittente alfanumerico | www.twilio.com2026-09-22 |
| Registrazione del mittente | www.agcom.it2026-09-22 |
| SMS bidirezionale | www.twilio.com2026-09-22 |
| Contenuti vietati | www.twilio.com2026-09-22 |
Casi d’uso
Codici monouso
Messaggio atteso, fuori dalla fascia vietata, con requisiti di latenza e stati affidabili. Coda separata da quella delle campagne.
Notifiche di ordine e spedizione
Attivate da un evento dell’e-commerce, con webhook di stato che aggiorna l’ordine. Il collegamento tra messaggio e ordine deve sopravvivere a un rinvio.
- Il vincolo orario vale per il canale API come per l’invio da interfaccia.
- L’alias va iscritto prima del primo invio: è configurazione, non parametro di richiesta.
FAQ
Un messaggio accettato dall’API è già consegnato?
No. L’accettazione indica che la richiesta è valida e presa in carico. Lo stato reale arriva dopo via webhook e, a seconda della rete, una ricevuta può essere emessa all’ingresso nella rete dell’operatore anziché alla consegna sul terminale.
Qual è il codice MCC dell’Italia?
222. Identifica il Paese negli scambi tra operatori mobili e serve a instradare il messaggio verso la rete nazionale corretta.
Come si gestisce la fascia oraria in un’integrazione?
Pianificando in ora italiana e separando le code per tipo di traffico. Una coda unica che si svuota di notte invia messaggi promozionali nella fascia vietata tra le 22:00 e le 08:00, con il rischio che vengano filtrati.
L’alias può essere passato come parametro a ogni richiesta?
Tecnicamente sì, ma in Italia è rischioso: l’alias deve essere iscritto al Registro AGCOM prima dell’uso. Un valore libero per richiesta permette di inviare con un nome non registrato, che viene bloccato senza che l’applicazione se ne accorga.
Documentazione e registrazione disponibili; l’attivazione commerciale per mercato viene verificata al pagamento.
SMSPro · 2 fonti · 2026-09-25