Qué es un webhook y cómo inicia una automatización

Cómo llega el aviso

El servicio que produce el evento necesita una dirección a la que enviarlo. La aplicación receptora prepara esa dirección y define cómo leer el mensaje. El aviso puede incluir información completa sobre el suceso o un identificador con el que consultar los detalles mediante una API.

Recibir el aviso y terminar el trabajo son momentos distintos. Por ejemplo, puede registrarse una solicitud para procesarla después. Diseñar esa separación permite explicar qué se ha recibido, qué está pendiente y qué se ha completado.

Ejemplo didáctico: una cita que cambia de hora

Una aplicación de agenda comunica que una cita se ha reprogramado. El receptor comprueba que el aviso pertenece al servicio esperado, identifica la cita y actualiza su referencia interna. A continuación prepara un aviso al equipo responsable con la nueva hora.

Si el mismo evento llega otra vez, el sistema reconoce su identificador y evita generar un segundo aviso equivalente. Si llega un cambio anterior después del más reciente, debe comprobar qué estado sigue vigente. El ejemplo ilustra problemas de diseño; el comportamiento exacto depende de las garantías del proveedor.

Webhook frente a consulta de una API

Consultar periódicamente una API significa preguntar si hay novedades. El webhook cambia esa dinámica: el servicio envía el aviso cuando se produce el evento. La elección depende de qué soporte la herramienta y de cuánto retraso admita el proceso.

Pueden combinarse. Un webhook puede iniciar el trabajo y una consulta posterior confirmar el estado actual. También puede existir una revisión periódica para detectar sucesos que no se procesaron. Ese mecanismo de recuperación necesita un criterio propio; no conviene dar por hecho que un aviso siempre llegará.

Cuándo resulta útil

Es útil cuando una acción debe comenzar a partir de un cambio concreto: formulario recibido, documento disponible, incidencia actualizada o ejecución terminada. Ayuda a conectar servicios sin mantener una comprobación constante para cada registro.

Antes de adoptarlo, identifica qué evento necesitas realmente. Un aviso de «registro creado» puede llegar antes de que estén todos sus datos; uno de «proceso completado» puede ser el punto correcto. El nombre del evento debe contrastarse con la documentación y con una prueba del recorrido.

Límites y comprobaciones básicas

Un webhook no es una garantía universal de entrega única, orden o autenticidad. Cada proveedor define su comportamiento. La documentación de Stripe, por ejemplo, contempla verificaciones de firma, reintentos y eventos duplicados; esas condiciones no deben extrapolarse sin revisar otros servicios.

• Verifica la procedencia con el mecanismo que admita el proveedor.
• Conserva un identificador para reconocer sucesos ya procesados.
• Define cómo recuperar una entrega fallida y cómo avisar de trabajo pendiente.
• Comprueba el resultado de negocio, además de la respuesta técnica del receptor.