Qué hace un webhook

Un webhook es una comunicación que un sistema envía a una dirección configurada cuando se produce un evento. Permite que el destinatario reaccione sin consultar continuamente si hay novedades. No es necesariamente un correo ni una alerta visible para el trabajador. Es un mecanismo entre aplicaciones que necesita un acuerdo sobre contenido y comportamiento.

Evento y estado no son lo mismo

Un aviso puede indicar que cambió una acción preventiva, pero no contener toda su información actual. El destinatario puede necesitar consultar el estado mediante una API autorizada. También debe saber si el evento describe una creación, modificación o eliminación. El diseño conecta con la trazabilidad de la gestión preventiva para interpretar qué sucedió.

Verificar quién envía

El receptor debe comprobar la autenticidad de la comunicación con el mecanismo previsto, además de utilizar un canal protegido. No basta con confiar en el texto recibido o en un identificador que cualquiera pueda copiar. Se limitan los datos personales incluidos y se controla quién configura destinos. Enviar información preventiva a una URL equivocada puede exponerla fuera del circuito autorizado.

Prepararse para duplicados y retrasos

La red puede fallar y el emisor puede repetir una entrega. Por ello se define cómo reconocer eventos procesados y cómo recuperar fallos. No debe suponerse que todos los proveedores garantizan orden, entrega única o reintentos ilimitados. Las condiciones se verifican en su documentación y se ensayan antes de utilizar el aviso para iniciar actuaciones importantes.

Ejemplo de integración

En un ejemplo hipotético, cerrar una inspección genera un evento para actualizar un cuadro de seguimiento. El receptor valida el mensaje, identifica la inspección y evita contar dos cierres si llega un duplicado. Si el aviso falla, un procedimiento de conciliación detecta la diferencia. La prueba comprueba el dato final y no solo que se haya enviado una solicitud.

No sustituir una comunicación de emergencia

Un webhook de gestión no debe asumirse apto para alertas críticas de seguridad sin un diseño específico, garantías y alternativas. Se acuerdan responsables, tiempos y seguimiento de incidencias. Los registros deben permitir investigar errores sin almacenar credenciales ni información sensible innecesaria. La integración se mantiene y revisa cuando cambian los sistemas participantes.