Overview
Si los webhooks de confirmaciones de entrega (DLR) de BroadNet no llegan a su servidor, la causa casi siempre está en el lado del receptor: no hay una URL de devolución de llamada configurada en la cuenta, la URL no es accesible públicamente a través de HTTPS o el punto final no devuelve HTTP 200 rápidamente. La plataforma envía un JSON DLR (MessageId, Status, BatchId y más) a su URL cuando cada mensaje llega a su estado final; primero revise la URL, la respuesta y su firewall.
No se ha configurado ninguna URL de devolución de llamada (o es incorrecta).
Los webhooks de DLR solo se activan si se ha configurado una URL de devolución de llamada en tu cuenta. Si no hay ninguna configurada, o si apunta a un host antiguo o incorrecto, no se entregará nada y no verás ningún error. Confirme la URL de DLR/webhook en la cuenta y, si no puede recibir notificaciones push, recurra a consultar el estado bajo demanda (en la API HTTP heredada: GET /websmpp/websmsstatus con el ID de respuesta).
- Los webhooks requieren que se haya configurado una URL de devolución de llamada en la cuenta.
- Una URL inexistente o desactualizada significa que la entrega no se realizará de forma silenciosa.
- Verifique que la URL DLR configurada esté actualizada.
- Alternativa: consultar el estado bajo demanda (API HTTP heredada: /websmpp/websmsstatus).
El punto final no es accesible públicamente a través de HTTPS.
La plataforma realiza solicitudes POST desde internet, por lo que usar localhost, una IP privada, un certificado TLS no confiable o autofirmado, o una lista de direcciones IP que excluya a nuestros remitentes, impedirá que se complete la llamada. Utilice un punto final HTTPS público con un certificado válido y, si usa una lista de direcciones permitidas, autorice las direcciones salientes de BroadNet. Pruebe la URL desde fuera de su red antes de culpar a la plataforma.
- Debe ser una URL HTTPS pública con un certificado válido.
- localhost, direcciones IP privadas y certificados autofirmados no recibirán.
- Si filtra el tráfico entrante, añada a la lista de remitentes permitidos de BroadNet.
- Para confirmar la accesibilidad, accede al punto final desde fuera de tu red mediante una comprobación con Curl.
El punto final no devuelve 200 rápidamente.
Tu endpoint debe responder con HTTP 200 inmediatamente. Si devuelve un código 4xx/5xx, se agota el tiempo de espera o se bloquea al realizar tareas pesadas, la entrega se considera fallida y se reintenta con un retroceso exponencial, lo que se manifiesta como webhooks "faltantes" o retrasados. Devuelve 200 inmediatamente y procesa el DLR de forma asíncrona (ponlo en cola y luego realiza el trabajo).
- Confirmación con HTTP 200 rápido.
- 5xx/4xx/tiempo de espera agotado → reintentos con retroceso (parece que se pierde).
- No hagas un trabajo lento antes de responder.
- Devuelve 200 y luego procesa el DLR fuera de la ruta de la solicitud.
No es un problema del webhook; el mensaje aún no es definitivo.
Un DLR solo se activa cuando un mensaje alcanza un estado terminal (DELIVRD o UNDELIV). Si un mensaje aún está en cola o programado, no se debe generar ningún informe todavía; esto es normal y no indica un fallo del webhook. Confirme el estado real del mensaje con una consulta de estado (API HTTP heredada: /websmpp/websmsstatus) antes de concluir que el webhook está roto y compare los informes por MessageId o BatchId.
- Los DLR se activan únicamente en el estado final (DELIVRD / UNDELIV).
- Los mensajes en cola o programados aún no tienen DLR.
- Verifique el estado real con una consulta de estado (API HTTP heredada: /websmpp/websmsstatus) antes de continuar con la depuración.
- Coincidencia de informes por MessageId o BatchId.