Cómo Enviar SMS y WhatsApp Más Rápido con la API de Sent.dm

TL;DR / Respuesta Rápida

La API de Sent.dm te ofrece un único punto de integración para la mensajería empresarial a través de SMS y WhatsApp. Si combinas Sent con Apidog, puedes almacenar tus credenciales en entornos, probar solicitudes sin escribir scripts desechables, validar cargas útiles de webhook y documentar tu flujo de trabajo de mensajería en un solo lugar.

Introducción

La mayoría de los proyectos de mensajería se ralentizan en el mismo punto: la API en sí no es difícil, pero los detalles operativos se acumulan rápidamente. Necesitas claves de API, una identidad de remitente, IDs de plantilla, seguridad de webhook, reglas de canal y una forma limpia de probar todo esto sin enviar mensajes reales a ciegas.

Esa es exactamente la razón por la que Sent.dm es interesante. Sent se posiciona como una API de mensajería unificada para SMS y canales basados en aplicaciones como WhatsApp, con lógica de enrutamiento y entrega gestionada detrás de una única interfaz orientada al desarrollador. Según la documentación pública de Sent revisada el 26 de marzo de 2026, la plataforma incluye verificación de cuenta, configuración de canal, envío basado en plantillas, contactos, eventos de webhook y un panel de control de pruebas.

Qué resuelve la API de Sent.dm

Sent.dm está diseñado para equipos que quieren llegar a los usuarios en más de un canal de mensajería sin tener que mantener integraciones separadas para cada proveedor. En lugar de conectar APIs de SMS, la incorporación de WhatsApp, formatos de carga útil específicos de cada canal y la monitorización de entregas por tu cuenta, Sent abstrae esa complejidad en una sola plataforma.

Según la documentación oficial, la historia del producto es sencilla:

• Una URL base de API para flujos de trabajo de mensajería
• Autenticación basada en cabeceras con x-api-key
• Un modelo de identidad de remitente usando x-sender-id
• Mensajería saliente basada en plantillas
• Gestión de contactos y audiencias
• Webhooks para eventos de entrega y plantilla
• Conceptos de enrutamiento inteligente y conmutación por error en la capa de la plataforma

Esa combinación es importante porque los sistemas de mensajería rara vez son solo "enviar texto y seguir adelante". También necesitas:

• Una estructura de carga útil consistente
• Una forma segura de reutilizar plantillas
• Seguimiento de eventos para mensajes entregados, fallidos o en cola
• Un flujo de trabajo de pruebas que mantenga los secretos fuera del código front-end
• Documentación que tus desarrolladores y compañeros de QA puedan usar realmente

Aquí está el desafío más grande en la práctica:

Aplicación -> API de Mensajes -> Reglas de Canal -> Eventos de Entrega -> Lógica de Reintento / Estado

Si cada parte reside en una herramienta diferente, la depuración se vuelve lenta. Una de las formas más fáciles de evitar que eso suceda es modelar todo el flujo en una plataforma API como Apidog desde el primer día.

Cómo funciona la API de Sent.dm

La documentación pública de Sent describe la plataforma como una capa de middleware inteligente entre tu aplicación y los canales de mensajería descendentes. La promesa es simple: tu aplicación envía una solicitud y Sent elige la mejor ruta de entrega basándose en la lógica de enrutamiento, el contexto del destinatario y la disponibilidad del canal.

Para los desarrolladores, las partes más importantes son la secuencia de configuración y el modelo de credenciales.

1. Configuración de cuenta y cumplimiento

El flujo oficial de inicio comienza con la creación de la cuenta, la verificación KYC y la configuración empresarial. Eso no es una tarea opcional. Los productos de mensajería están sujetos a reglas de cumplimiento, reputación del remitente y restricciones regionales, por lo que Sent hace que la verificación de la cuenta sea parte del proceso de incorporación.

2. Configuración del canal

La documentación de Sent te guía para elegir un número de teléfono y conectar WhatsApp Business. La documentación recomienda usar el mismo número para SMS y WhatsApp para que la identidad de tu marca se mantenga consistente en todos los canales.

3. Plantillas

Las plantillas son una parte fundamental del flujo de trabajo. En la guía de inicio, Sent te pide que crees una plantilla antes de enviar tu primera solicitud de API. Esa es una buena señal de que la mensajería basada en plantillas no es un caso excepcional aquí. Es parte del camino predeterminado.

4. Credenciales de la API

La documentación muestra dos credenciales:

x-sender-id: TU_ID_DE_REMITENTE
x-api-key: TU_CLAVE_DE_API

La referencia de la API v3 destaca x-api-key como la cabecera de autenticación requerida. Los ejemplos de inicio también incluyen x-sender-id para las solicitudes de mensajes. Cuando implementes esto en producción, verifica los requisitos exactos de las cabeceras con tu espacio de trabajo actual y la versión del endpoint en el panel de Sent, ya que la documentación muestra tanto una vista de referencia v3 como ejemplos de mensajes v2.

5. Solicitud de mensaje

La guía de inicio muestra una solicitud a:

POST https://api.sent.dm/v2/messages/phone

con una carga útil JSON con esta forma:

{
 "phoneNumber": "NUMERO_DE_TELEFONO_DEL_RECEPTOR",
 "templateId": "ID_DE_PLANTILLA"
}

Esto te dice algo importante sobre el primer objetivo de implementación: el camino más rápido no es construir un servicio gigante de orquestación omnicanal. Es configurar los envíos basados en plantillas correctamente, y luego expandir el flujo de trabajo una vez que puedas observar el comportamiento de la solicitud y la entrega de forma fiable.

Envía tu primera solicitud a la API de Sent.dm

Construyamos la primera solicitud de una manera que sea fácil de probar y fácil de mantener.

Ejemplo de cURL

curl -X POST "https://api.sent.dm/v2/messages/phone" \
 -H "x-sender-id: TU_ID_DE_REMITENTE" \
 -H "x-api-key: TU_CLAVE_DE_API" \
 -H "Content-Type: application/json" \
 -d '{
 "phoneNumber": "NUMERO_DE_TELEFONO_DEL_RECEPTOR",
 "templateId": "ID_DE_PLANTILLA"
 }'

Ejemplo de JavaScript

const response = await fetch("https://api.sent.dm/v2/messages/phone", {
 method: "POST",
 headers: {
 "x-sender-id": process.env.SENT_SENDER_ID,
 "x-api-key": process.env.SENT_API_KEY,
 "Content-Type": "application/json"
 },
 body: JSON.stringify({
 phoneNumber: process.env.TEST_PHONE_NUMBER,
 templateId: process.env.SENT_TEMPLATE_ID
 })
});

if (!response.ok) {
 throw new Error(`La solicitud de Sent falló: ${response.status}`);
}

const data = await response.json();
console.log(data);

Ejemplo de Python

import os
import requests

response = requests.post(
 "https://api.sent.dm/v2/messages/phone",
 headers={
 "x-sender-id": os.environ["SENT_SENDER_ID"],
 "x-api-key": os.environ["SENT_API_KEY"],
 "Content-Type": "application/json",
 },
 json={
 "phoneNumber": os.environ["TEST_PHONE_NUMBER"],
 "templateId": os.environ["SENT_TEMPLATE_ID"],
 },
 timeout=30,
)

response.raise_for_status()
print(response.json())

Según la documentación de inicio, una respuesta exitosa devuelve HTTP 200 y un messageId. Ese messageId es el valor que querrás capturar en las pruebas de Apidog, los registros de la aplicación, los flujos de trabajo de soporte y la conciliación de webhooks.

Prueba la API de Sent.dm en Apidog

Aquí es donde Apidog se convierte en algo más que un ejecutor de solicitudes. Las APIs de mensajería son más fáciles de trabajar cuando la solicitud, las variables, las aserciones de prueba, la documentación y el traspaso del equipo conviven en un mismo lugar.

Paso 1: Crear un entorno Sent

En Apidog, crea un entorno con variables como:

base_url = https://api.sent.dm
sender_id = TU_ID_DE_REMITENTE
api_key = TU_CLAVE_DE_API
template_id = TU_ID_DE_PLANTILLA
test_phone = NUMERO_DE_TELEFONO_DEL_RECEPTOR

El uso de variables de entorno te proporciona tres beneficios inmediatos:

1. Evitas codificar directamente secretos de producción en los ejemplos.
2. Puedes cambiar entre cuentas de sandbox, staging y en vivo más rápidamente.
3. Los compañeros de equipo pueden reutilizar la misma colección con sus propios valores seguros.

Paso 2: Construye la solicitud una vez

Crea una nueva solicitud en Apidog:

- x-sender-id: {{sender_id}} - x-api-key: {{api_key}} - Content-Type: application/json

• Método: POST
• URL: {{base_url}}/v2/messages/phone
• Cabeceras:
• Cuerpo:

{
 "phoneNumber": "{{test_phone}}",
 "templateId": "{{template_id}}"
}

Esto ya es mejor que las pruebas puntuales en terminal porque tu equipo puede inspeccionar la forma exacta de la carga útil, el modelo de autenticación y la respuesta esperada en un solo lugar.

Paso 3: Añadir aserciones

En Apidog, añade pruebas que validen la ruta de éxito.

Ejemplos de comprobaciones:

pm.test("El estado es 200", function () {
 pm.response.to.have.status(200);
});

pm.test("La respuesta contiene un messageId", function () {
 const json = pm.response.json();
 pm.expect(json.messageId).to.exist;
});

Estas comprobaciones te ayudan a detectar errores sutiles rápidamente. Si la solicitud deja de devolver un ID de mensaje después de un cambio de API, una rotación de credenciales o un problema de plantilla, lo verás de inmediato.

Paso 4: Conviértelo en un escenario

Apidog se vuelve aún más útil cuando pasas de una única solicitud a un flujo de trabajo:

1. Enviar un mensaje
2. Almacenar el messageId devuelto
3. Consultar el estado posterior si tu configuración expone ese flujo
4. Comparar los eventos de mensajes recibidos a través de webhooks

Ese es el nivel adecuado de prueba de API para sistemas de mensajería, porque un POST exitoso no significa que tu flujo de negocio esté sano. También te interesan las aprobaciones, la entrega, los reintentos y la consistencia de los eventos.

Paso 5: Añade ejemplos de webhook a la misma colección

Una vez que tu solicitud de envío funcione, añade ejemplos guardados para los eventos de webhook que tu equipo espera recibir. Eso te da una única colección que cubre las solicitudes salientes y la gestión de eventos entrantes.

Por ejemplo, puedes guardar un ejemplo de carga útil de webhook y documentar campos como:

{
 "field": "message.status",
 "messageId": "msg_123",
 "status": "delivered",
 "channel": "whatsapp"
}

Esto da sus frutos rápidamente. Los ingenieros de backend pueden comparar las cargas útiles en vivo con el ejemplo guardado, el control de calidad puede validar la lógica de manejo de eventos y los equipos de soporte pueden comprender lo que significan los estados de los mensajes sin tener que buscar en los registros.

Paso 6: Publicar documentos internos

Si tu equipo cuenta con ingenieros de backend, control de calidad, soporte y partes interesadas del producto que tocan el mismo flujo de mensajería, la capa de documentación de Apidog ahorra tiempo. En lugar de compartir un conjunto suelto de fragmentos de cURL en el chat, puedes publicar una referencia interna limpia que incluya:

• Cabeceras requeridas
• Ejemplos de cargas útiles
• Respuestas de error
• Ejemplos de eventos de webhook
• Notas de entorno

Eso es un traspaso mucho más sólido que "ejecuta este script y dime qué pasó".

Maneja plantillas, contactos y webhooks de la manera correcta

Lograr que la primera solicitud devuelva 200 es solo el comienzo. El verdadero trabajo de producción comienza después de eso.

Plantillas

El flujo de incorporación de Sent enfatiza fuertemente las plantillas, especialmente para la mensajería relacionada con WhatsApp. Esto significa que tu implementación de API debe tratar las plantillas como contenido versionado, no solo como IDs copiadas en un archivo una vez y olvidadas.

Un patrón práctico es:

1. Mantener los ID de plantilla en variables de entorno o configuración
2. Etiquetar cada plantilla por propósito, idioma y estado de aprobación
3. Separar las plantillas de prueba de las plantillas de campañas en vivo
4. Documentar qué plantillas se corresponden con qué viajes de usuario

Apidog ayuda aquí porque puedes crear solicitudes de ejemplo para cada plantilla aprobada y mantenerlas junto a tu colección de API más amplia.

Contactos

La documentación de Sent presenta los contactos como un área de características de primera clase. Incluso si tu aplicación ya almacena usuarios internamente, los objetos de contacto en una plataforma de mensajería son útiles para operaciones a nivel de audiencia, segmentación por plantilla e historial de comunicación.

Si construyes una lógica de sincronización de contactos, documenta estas reglas con antelación:

• Qué sistema es la fuente de la verdad
• Cómo se normalizan los números de teléfono
• Cómo se almacena el estado de opt-in o consentimiento
• Qué sucede cuando un contacto cambia de canal

Esos no son detalles para limpiar más tarde. Afectan la entregabilidad y el cumplimiento desde el principio.

Webhooks

La documentación de webhooks de Sent es una de las partes más importantes de la plataforma para un uso de producción real. La documentación describe la verificación de firma HMAC-SHA256 con cabeceras que incluyen:

• x-webhook-signature
• x-webhook-id
• x-webhook-timestamp

La documentación también describe el formato de la firma como v1,{base64_signature} y recomienda la protección contra la repetición con una ventana de tiempo de cinco minutos.

Eso te da una lista de verificación de producción limpia:

1. Leer el cuerpo de la solicitud en bruto
2. Verificar la firma antes de analizarla
3. Rechazar marcas de tiempo antiguas
4. Procesar eventos de forma idempotente
5. Acusar recibo rápidamente y mover el trabajo pesado a trabajos en segundo plano

Aquí tienes un ejemplo compacto de Express:

import crypto from "crypto";
import express from "express";

const app = express();

app.post("/webhooks/sent", express.raw({ type: "*/*" }), (req, res) => {
 const signature = req.header("x-webhook-signature");
 const webhookId = req.header("x-webhook-id");
 const timestamp = req.header("x-webhook-timestamp");
 const secret = process.env.SENT_WEBHOOK_SECRET;
 const rawBody = req.body.toString("utf8");

 const signedContent = `${webhookId}.${timestamp}.${rawBody}`;
 const expected = crypto
 .createHmac("sha256", Buffer.from(secret.replace(/^whsec_/, ""), "base64"))
 .update(signedContent)
 .digest("base64");

 if (signature !== `v1,${expected}`) {
 return res.status(401).send("No autorizado");
 }

 const event = JSON.parse(rawBody);
 console.log("Evento de webhook recibido:", event.field);

 return res.sendStatus(200);
});

Usa Apidog para almacenar ejemplos de cargas útiles de webhook y documentar los eventos esperados. Esto facilita que los equipos de front-end, back-end y QA se alineen en el mismo ciclo de vida del mensaje.

Por qué Apidog se adapta a este flujo de trabajo

Sent.dm te proporciona la capa de mensajería. Apidog te proporciona la capa de flujo de trabajo alrededor de esa capa de mensajería.

Aquí está la diferencia práctica:

Si tu equipo está evaluando Sent para la mensajería de aplicaciones, Apidog cubre la capa que Sent no intenta ser: diseño colaborativo de API, pruebas, depuración, planificación de mocks y documentación en un solo espacio de trabajo.

Esto es útil en al menos tres situaciones:

• Estás incorporando a varios desarrolladores y necesitas una colección de solicitudes compartible
• Quieres que QA valide las APIs de mensajería sin escribir scripts personalizados
• Necesitas un lugar repetible para probar cambios de versión, nuevas plantillas o cargas útiles de webhook

Descarga Apidog gratis para probar las solicitudes de Sent.dm, almacenar entornos de mensajería de forma segura y convertir tu primera llamada exitosa a la API en un flujo de trabajo de equipo reutilizable.

Consejos avanzados y errores comunes

Una vez que el flujo básico funciona, estas prácticas hacen que la integración sea más fiable.

Mejores prácticas

1. Mantén las credenciales solo en el lado del servidor. La documentación de Sent advierte explícitamente contra la exposición de claves de API en el código del lado del cliente.
2. Rastrea el messageId en los registros de tu aplicación y en las herramientas de soporte.
3. Separa las plantillas de staging y de producción.
4. Verifica cada webhook antes de procesarlo.
5. Usa los entornos de Apidog para aislar las credenciales en vivo de las credenciales de prueba.

Errores comunes a evitar

1. Tratar una respuesta 200 como el resultado final de la entrega en lugar del inicio del ciclo de vida del evento.
2. Codificar IDs de plantilla en múltiples servicios.
3. Ignorar la configuración de la identidad del remitente hasta tarde en el despliegue.
4. Olvidarse de normalizar los números de teléfono de forma consistente.
5. Probar con credenciales reales en scripts ad-hoc que nadie más puede inspeccionar.

Puntos para la resolución de problemas

Si una solicitud no funciona, verifica lo siguiente en orden:

1. ¿Es la x-api-key válida y activa?
2. ¿Coincide el endpoint al que estás llamando con la versión mostrada en tu espacio de trabajo de Sent?
3. ¿Es necesario x-sender-id para esa ruta de solicitud?
4. ¿Está la plantilla aprobada y disponible para el canal elegido?
5. ¿Estás enviando a un número de teléfono en el formato correcto?

Apidog ayuda aquí porque puedes comparar una solicitud fallida con una solicitud guardada conocida que funciona en segundos.

Alternativas y comparaciones de Sent.dm

Si estás evaluando Sent.dm, probablemente también estés considerando integraciones directas con proveedores, plataformas de comunicaciones más amplias, o un cliente de API familiar como Postman para las pruebas diarias. La principal diferencia es el control frente a la simplicidad, y la capa de pruebas es tan importante como la capa de entrega.

Para los equipos que valoran la velocidad del desarrollador, la mejor configuración a menudo no es "elegir una herramienta para todo". Es emparejar la plataforma de entrega con una sólida capa de colaboración de API. Si ya usas Postman, la razón más sólida para considerar Apidog aquí no es el envío básico de solicitudes. Es tener entornos, documentos guardados, aserciones, planificación de mocks y traspaso de equipo en un solo espacio de trabajo.

Conclusión

Sent.dm es una API de mensajería útil para equipos que desean una plataforma única para SMS y WhatsApp en lugar de integraciones de canales separadas. La mayor ventaja no es solo que puedes enviar un mensaje. Es que puedes probar y construir en torno a plantillas, identidad del remitente, contactos y webhooks de una manera más estructurada.

Si quieres avanzar más rápido, empieza por construir la primera solicitud de Sent en Apidog, añade aserciones para messageId, y luego documenta tu contrato de webhook en el mismo espacio de trabajo. Eso te proporciona un camino más limpio desde el prototipo hasta la producción que depender de scripts dispersos y conocimiento tribal.

Preguntas Frecuentes

¿Para qué se utiliza la API de Sent.dm?

La API de Sent.dm se utiliza para la mensajería empresarial a través de canales como SMS y WhatsApp mediante una única integración. Según la documentación oficial, soporta la configuración del remitente, plantillas, contactos y el manejo de eventos basado en webhooks.

¿Sent.dm soporta WhatsApp y SMS en una sola API?

Sí. Sent posiciona la plataforma como una API de mensajería unificada que abstrae la complejidad específica de cada canal detrás de una única integración para desarrolladores. La documentación de incorporación también recomienda usar el mismo número de teléfono tanto para SMS como para WhatsApp.

¿Qué cabeceras necesito para las solicitudes a la API de Sent.dm?

La documentación pública muestra x-api-key como la cabecera de autenticación principal, y los ejemplos de mensajes de inicio también usan x-sender-id. Verifica la versión exacta del endpoint en tu cuenta de Sent antes del despliegue en producción, ya que la documentación muestra referencias tanto de v3 como de v2.

¿Necesito plantillas antes de enviar mensajes con Sent.dm?

Para el flujo de inicio, sí. La guía de incorporación de Sent te lleva a través de la creación de una plantilla y luego el envío del primer mensaje con un templateId.

¿Cómo pruebo la API de Sent.dm sin escribir scripts personalizados?

Apidog es una buena opción para esto. Puedes almacenar tus credenciales de Sent como variables de entorno, guardar solicitudes de mensajes, añadir aserciones, construir escenarios de varios pasos, documentar cargas útiles de webhook y publicar documentación interna de la API para el resto de tu equipo.

¿Cómo debo proteger los webhooks de Sent.dm?

Verifica la firma HMAC, valida la marca de tiempo y procesa los eventos de forma idempotente. La documentación de Sent describe cabeceras como x-webhook-signature, x-webhook-id y x-webhook-timestamp para la verificación.

¿Es Sent.dm suficiente por sí solo para los flujos de trabajo API de un equipo?

Cubre la plataforma de mensajería en sí, pero la mayoría de los equipos todavía necesitan una herramienta colaborativa de API para pruebas, documentación y validación repetida. Ahí es donde Apidog añade valor.