Enviar un SMS con contenido libre (payload)
Cómo enviar texto generado por tu aplicación y qué cuidar en codificación y webhooks de prueba.
Cuando el contenido lo genera tu aplicación en tiempo real (por ejemplo un código de verificación dinámico), usa payload en lugar de template.
Petición
POST {URL_BASE}
Content-Type: application/json
X-API-Key: <su API key>{
"contact": "<numero del destinatario>",
"channel": 1,
"senderId": "<su Sender ID>",
"webhook": "<su URL de webhook>",
"payload": {
"type": "text",
"text": "Su codigo de verificacion es 482913. Vigencia 10 minutos."
}
}En Postman, usa la pestaña Body en modo raw/JSON. Un envío correcto devuelve 202 Accepted y error: false.
Cuidado con acentos y eñes en el texto
Si tu mensaje usa únicamente el alfabeto GSM-7 (sin acentos, sin eñes, sin emojis), cada SMS admite hasta 160 caracteres. Basta un solo carácter fuera de ese alfabeto para que el mensaje pase a codificación UCS-2, con un límite de 70 caracteres por SMS, y el costo del envío sube en la misma proporción.
Los mensajes más largos que el límite se dividen en partes concatenadas (153 caracteres por parte en GSM-7, 67 en UCS-2), y cada parte se factura por separado.
| Codificación | Caracteres por SMS | Caracteres por parte concatenada |
|---|---|---|
| GSM-7 | 160 | 153 |
| UCS-2 | 70 | 67 |
Crítico: la URL de la vista de webhook.site no es la URL de callback
Si usas webhook.site para pruebas, es fácil copiar por error la URL de la vista web del navegador, que incluye un fragmento #!/view/.
- Incorrecta:
https://tu-servidor.com/#!/view/<id> - Correcta:
https://tu-servidor.com/<id>
Todo lo que va después de # nunca se envía al servidor. Con la URL incorrecta, tu SMS se entrega normalmente pero el DLR nunca llega a tu endpoint de pruebas.