Cómo enviar alertas a Teams y Slack desde scripts con webhooks seguros

Si trabajas con infraestructuras en la nube, CI/CD, monitorización o gestión de incidentes, seguramente quieras que todas las alertas importantes aterricen directamente en tus canales de Microsoft Teams o Slack. La forma más flexible y sencilla de conseguirlo desde scripts, automatizaciones o servicios externos es usar webhooks… siempre que los protejas bien.

En los últimos años el panorama ha cambiado: conectores antiguos como los de Office 365 en Teams se están retirando, las políticas de DLP son cada vez más estrictas y muchos servicios solo hablan JSON con formatos muy particulares (como Amazon SNS, Azure Monitor o ClickUp). Todo esto hace que integrar alertas con Teams y Slack no sea solo “pegar una URL” y ya está, sino pensar en seguridad, formatos de payload y arquitectura.

Qué es realmente un webhook y por qué es tan útil para alertas

Un webhook no es más que una URL HTTP o HTTPS que acepta peticiones POST desde otro sistema. Cada vez que se dispara un evento (un error en producción, un despliegue fallido, un cambio de estado en un recurso, etc.), tu script o servicio envía un JSON a esa URL y el mensaje aparece en el canal de Teams o Slack que hayas elegido.

En este esquema, Teams y Slack actúan como receptores pasivos: solo esperan que alguien les mande una petición con el formato adecuado. La ventaja es que, desde tu lado, puedes usar prácticamente cualquier lenguaje o entorno: PowerShell, Bash, Python, AWS Lambda, Azure Functions, pipelines de CI, aplicaciones on‑premise, lo que quieras.

Es importante tener claro que cada plataforma espera una estructura JSON concreta. Por ejemplo, un webhook de Slack o Microsoft Teams suele requerir al menos un campo con el texto del mensaje (normalmente «text»), mientras que otros servicios como Amazon Chime esperan claves diferentes (por ejemplo «Content»).

Otro punto clave es que muchos servicios de nube (Azure, AWS, ClickUp, etc.) no envían exactamente el formato que Teams o Slack esperan, sino su propio esquema de payload para eventos y alertas. Por eso, a menudo necesitas una “pieza intermedia” que adapte esa información al formato correcto.

Tipos de integraciones: webhooks, conectores, bots y APIs

En el mundo de Microsoft Teams hay varias formas de recibir notificaciones automáticas desde scripts o servicios externos, y conviene distinguirlas para elegir bien la arquitectura:

Por un lado están los webhooks entrantes, que son la opción más directa para mandar mensajes a un canal de Teams. Activando esta característica en un canal se genera una URL HTTPS que acepta JSON y “pincha” el contenido en la conversación. No requieren instalar una app compleja, ni recursos adicionales en Azure; es una funcionalidad nativa del canal.

En el otro extremo tienes la API de notificaciones y los bots de notificación, que forman parte de las capacidades más avanzadas de Teams. Aquí ya hablamos de aplicaciones completas de Teams que pueden enviar notificaciones enriquecidas a usuarios, chats o canales, aprovechar Microsoft Graph, recuperar contexto del usuario, mostrar contenido en paneles, etcétera. Es ideal si buscas experiencias personalizadas, tarjetas adaptables dinámicas y reglas de negocio elaboradas.

También entran en juego los conectores para Grupos de Microsoft 365, que permiten empaquetar un webhook con una página de configuración propia como parte de una app de Teams. Suelen usar tarjetas de conector con un conjunto limitado de acciones, perfectas para integraciones “de producto” como conectores de clima, incidencias, etc.

Finalmente, está la API de notificación basada en Graph, que funciona como un endpoint RESTful para disparar notificaciones en el feed de actividad de Teams. Es muy potente cuando quieres que tu aplicación web o backend envíe avisos urgentes, con sonido y notificación del sistema operativo, sobre información crítica dirigida a usuarios concretos o grupos.

Adiós a los conectores de Office 365: por qué toca moverse a Power Automate

Si llevas años mandando mensajes a Teams usando los webhooks de conectores de Office 365, es probable que te hayas encontrado con avisos de que esta funcionalidad se está retirando. Microsoft está alineando el ecosistema con su estrategia de “futuro seguro”, lo que en la práctica significa empujar hacia soluciones más modernas y controladas, como Power Automate y las APIs actuales.

La forma recomendada de seguir enviando alertas desde scripts es orquestar el envío a Teams mediante un flujo de Power Automate. En lugar de llamar directamente a un webhook de Office 365, tus scripts disparan un trigger HTTP de Power Automate, y este flujo se encarga de construir y mandar el mensaje al canal de Teams usando conectores soportados.

En un escenario típico, creas un flujo de nube con un desencadenador tipo “Cuando se reciba una petición HTTP”. Desde tu script en PowerShell, Bash o Python haces un POST a ese endpoint, pasándole los datos relevantes (severidad, origen, descripción del incidente, etc.). El flujo procesa el JSON, lo transforma en una tarjeta o mensaje adaptado a Teams, y lo publica en el canal que elijas.

Esta aproximación tiene varias ventajas: te abstrae de cambios futuros en conectores, te permite centralizar la lógica de formateo y enrutamiento de alertas, y facilita cumplir requisitos de seguridad y cumplimiento, ya que Power Automate puede integrarse con DLP y gobernanza de Microsoft 365.

Proteger tus webhooks: tokens, inquilinos y DLP

Una de las grandes dudas cuando se expone una URL de webhook es cómo evitar que cualquiera pueda mandar mensajes a tu canal si descubre esa dirección. Aunque los webhooks son muy cómodos, hay que tratarlos como credenciales sensibles.

Un patrón muy utilizado consiste en añadir un token de autorización como parámetro en la URL. Por ejemplo, un endpoint puede tener este aspecto: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalue. El servicio que recibe la llamada comprueba que el token es válido antes de procesar la petición. De esa forma, aunque alguien vea la URL sin el token correcto, no podrá usarla.

En entornos Azure y Microsoft 365 es habitual ir un paso más allá y registrar una aplicación en Microsoft Entra ID (el antiguo Azure AD) para proteger el endpoint HTTP. El flujo de Power Automate puede estar publicado detrás de un API Management o una función protegida con Entra, de modo que solo scripts autenticados pertenecientes a tu tenant puedan disparar el webhook.

Además, muchas organizaciones aplican políticas de prevención de pérdida de datos (DLP) sobre entornos como Power Automate o Power Apps. Estas políticas pueden bloquear o restringir el uso de ciertos conectores (por ejemplo, mandar datos desde un entorno “confidencial” a conectores considerados “no de confianza” como un webhook de Teams). Si te encuentras con errores al guardar un flujo o al ejecutarlo, puede que la raíz esté precisamente en DLP.

En ese caso, toca revisar junto con el equipo de TI o gobernanza cómo está configurada la segmentación de conectores y realizar ajustes para permitir que tu webhook de Teams o Slack forme parte de los conectores permitidos en el entorno donde corre tu flujo o aplicación.

Formato de las cargas JSON: de Azure Monitor a Teams y Slack

Servicios como Azure Monitor, el registro de actividad de Azure o sistemas de seguridad generan eventos de alerta con esquemas JSON muy ricos y detallados. Cuando estos eventos se envían a un webhook como parte de un grupo de acciones, la carga que recibe tu endpoint incluye muchísima información, no solo el texto del mensaje.

El esquema típico de una notificación de alerta del registro de actividad de Azure incluye un campo schemaId y un objeto data que contiene el estado de la alerta, el contexto y las propiedades. Dentro de data.context.activityLog aparecen datos como el tipo de canal, el correlationId, la marca de tiempo del evento, el nivel (Critical, Error, Warning, Informational), el operationName, el identificador de recurso afectado y más.

Dependiendo del valor de eventSource en esa carga, la estructura concreta varía: hay eventos de tipo Administrative, Security, Recommendation, ServiceHealth o ResourceHealth, cada uno con sus propias propiedades específicas. Por ejemplo, un evento de seguridad puede detallar intentos de fuerza bruta SSH, IP de los atacantes, usuarios usados, número de intentos fallidos y pasos de remediación sugeridos.

Otros elementos de la carga incluyen campos como authorization (acción y ámbito del control de acceso basado en roles), caller (email o UPN del usuario que realizó la operación), eventDataId (identificador único), subStatus (frecuentemente con códigos HTTP como 200, 400, 404, 500, etc.), y un diccionario de properties con pares clave‑valor que añaden más contexto del evento.

Para que todo esto llegue a Teams o Slack de forma útil, no tiene sentido copiar el JSON entero tal cual. Lo práctico es que tu script o función extraiga los campos relevantes (recurso afectado, severidad, descripción, timestamps críticos, correlación) y construya un mensaje más legible, indicando de forma clara qué ha pasado, dónde y qué hacer a continuación.

De Amazon SNS a Slack, Teams y Chime con Lambda

Amazon Simple Notification Service (SNS) es otra pieza clave cuando quieres reaccionar a eventos de AWS y mandarlos a canales de chat. SNS puede publicar mensajes a endpoints HTTP/HTTPS, pero no siempre en el formato que los webhooks de Slack, Microsoft Teams o Amazon Chime esperan.

Por ejemplo, cuando configuras un tema de SNS para publicar en un webhook, la carga JSON de la notificación tiene sus propias claves (Message, Subject, Timestamp, etc.). Sin embargo, Slack y Teams esperan que el cuerpo de la petición incluya una clave «text» con el mensaje que se mostrará en el canal, mientras que Amazon Chime busca una clave «Content». SNS no soporta directamente transformar ese formato en el momento de la publicación.

La solución recomendada en AWS es usar una función Lambda como capa intermedia. En lugar de suscribir el webhook directamente al tema de SNS, creas un tema SNS, configuras una función Lambda que se suscribe a ese tema, y desde Lambda envías el POST al webhook con el JSON transformado a la estructura correcta.

El flujo sería algo así: SNS publica el evento en la función Lambda; la función lee event[«Records»][0][«Sns»][«Message»], arma un diccionario con la clave adecuada («Content» para Chime, «text» para Slack o Teams, añadiendo opcionalmente channel, username o icon_emoji en el caso de Slack), serializa a JSON y hace la petición POST usando una librería HTTP como urllib3.

En código Python, el esqueleto básico es muy directo: creas un PoolManager, defines la URL del webhook, construyes el mensaje con los campos esperados, lo conviertes a JSON codificado en UTF‑8 y envías la petición. Después, puedes registrar el status_code y el cuerpo de la respuesta para depuración, comprobando que el webhook acepte correctamente el mensaje (código 200) o identificando errores 4xx si hay parámetros inválidos o la URL es incorrecta.

Una vez validado el comportamiento de Lambda con un evento de prueba en la consola (usando la plantilla de “Notificación de tema de SNS”), lo siguiente es añadir el tema SNS como disparador de la función. Así, cada vez que un servicio publique en el tema (por ejemplo, CloudWatch Alarms, eventos de estado de instancias, etc.), la alerta acabará en Slack, Teams o Chime con el formato ideal.

Webhooks en Microsoft Teams: entrantes, salientes y conectores

Dentro de Teams hay varios tipos de conectividad que van más allá del típico webhook entrante y conviene conocerlos para diseñar mejor tu solución de alertas.

Los webhooks salientes permiten que desde un canal se pueda “llamar” a un servicio externo usando una mención tipo @. Configuras el webhook saliente con la URL de tu servicio y, cuando un usuario lo invoca con un mensaje, Teams envía el texto a tu endpoint y espera una respuesta rápida (normalmente en 10 segundos) con contenido que puede ser texto plano o una tarjeta. Es útil para comandos o consultas bajo demanda, no tanto para alertas automáticas.

Los webhooks entrantes, como hemos comentado antes, son perfectos para recibir alertas y notificaciones periódicas desde aplicaciones externas. Creas un webhook en un canal (por ejemplo, un canal DevOps) y configuras tus pipelines, scripts de despliegue, herramientas de monitorización o sistemas de seguridad para que envíen sus eventos a esa URL mediante HTTP POST.

Luego están los conectores para Grupos de Microsoft 365, que funcionan como una forma de empaquetar un webhook entrante con una interfaz de configuración dentro de Teams. Suelen enviar mensajes en forma de tarjetas de conector y permiten una experiencia más “de producto”, como seleccionar una ubicación en un conector de clima, programar horarios de notificación, etc.

Desde el punto de vista de arquitectura, si tu necesidad principal es que tus scripts y herramientas envíen mensajes a un canal sin demasiadas virguerías visuales, un webhook entrante sencillo suele ser más que suficiente. Si buscas lógica compleja, personalización avanzada y acciones interactivas, entonces un bot de notificación o una app de Teams con API de notificación es más apropiada.

Cómo crear un webhook entrante en Teams y usarlo desde un servicio externo

El proceso para habilitar un webhook entrante en un canal de Teams es bastante mecánico, pero conviene entender bien cada paso para integrarlo luego con tus scripts o aplicaciones.

Primero, en la interfaz de Teams eliges el equipo y el canal estándar donde quieres que aparezcan las alertas. Puede ser un canal existente (por ejemplo, “Incidencias”) o uno nuevo creado solo para integraciones.

Después haces clic en los tres puntos junto al nombre del canal y seleccionas la opción de Conectores. En la lista de conectores disponibles buscas “Webhook entrante” y pulsas en “Configurar”. A continuación, asignas un nombre que identifique para qué vas a usarlo (por ejemplo, “Alertas de CertSecure”, “Alertas de CI/CD” o “Monitorización Azure”) y, opcionalmente, subes un icono para que sea más fácil reconocer el origen de los mensajes.

Cuando confirmas la creación, Teams genera una URL única de webhook. Esa dirección es la que copiarás y pegarás en la configuración de tu herramienta o servicio externo. Es importante guardarla de forma segura, ya que quien tenga acceso a ella podría mandar mensajes al canal en tu nombre.

Algunos productos, como soluciones de gestión de certificados (por ejemplo, CertSecure), tienen en su propio portal de administración una sección específica para integrar Teams. Allí suelen pedirte que pegues la URL de webhook; tras guardarla, el sistema envía un mensaje de prueba al canal del equipo indicando que la integración se ha completado con éxito.

A partir de ahí, puedes activar o desactivar distintos eventos de notificación (emisión de nuevos certificados, revocaciones, renovaciones, vencimientos o alertas previas a la caducidad) para que cada cambio relevante genere un mensaje automático en el canal, manteniendo al equipo al día sin necesidad de entrar continuamente al panel de la herramienta.

Problemas habituales con ClickUp, Slack y otros servicios

No todas las plataformas encajan a la primera con los webhooks de Slack o Teams, incluso cuando aparentemente solo hay que pegar una URL. Un caso típico es el de ClickUp y Slack cuando se quiere notificar al canal cada vez que cambia el estado de una carpeta o lista.

ClickUp permite configurar automatizaciones en las que, ante un cambio de estado, se dispara una acción que envía una petición a una URL de webhook (por ejemplo, la URL de Slack que genera un webhook entrante). El problema es que ClickUp envía su propio payload JSON con un esquema que no coincide con lo que Slack espera, de modo que la notificación puede no aparecer en el canal.

En Slack, el webhook entrante suele esperar algo tan sencillo como { "text": "Mensaje a mostrar" }, con algunos campos opcionales como canal, nombre de usuario o icono. Si en lugar de eso recibe un JSON anidado con campos específicos de ClickUp, puede ignorar la petición o interpretarla mal, lo que se traduce en una alerta que nunca llega a verse.

La mejor forma de resolver este tipo de incompatibilidades es introducir una capa intermedia que haga de traductor, igual que en el caso de SNS y Lambda. En lugar de apuntar el webhook de ClickUp directamente a Slack, lo diriges a un endpoint propio (una función en la nube, una pequeña API en tu backend). Ese endpoint recibe el JSON de ClickUp, elige la información relevante (por ejemplo, nombre de la tarea, estado anterior y nuevo, responsable) y construye el JSON mínimo que Slack necesita, enviando después la petición al webhook entrante de Slack.

Este patrón se puede generalizar a muchas otras herramientas que “mandan JSON” pero no en el formato exigido por Slack o Teams. Al tener tu propia capa de integración, tienes control total sobre formato, filtrado, seguridad y enriquecimiento de mensajes, y puedes manejar cambios en las APIs sin tener que tocar la configuración de todos tus scripts.

Aprovechar los webhooks seguros para enviar alertas desde scripts a Teams y Slack implica algo más que copiar y pegar URLs: conviene entender los distintos tipos de integraciones de Teams, los esquemas JSON de servicios como Azure Monitor y Amazon SNS, el papel de capas intermedias como Power Automate o AWS Lambda, y las medidas de seguridad y DLP que rodean a todo esto; si diseñas bien esa arquitectura, tus equipos disfrutarán de alertas ricas, fiables y en tiempo real, sin sustos por cambios de conectores obsoletos ni por formatos incompatibles que se traguen silenciosamente tus notificaciones.