Webhooks en N8N: guía práctica para recibir datos

Casi toda automatización útil empieza con un evento: un formulario enviado, un pago aprobado, un mensaje recibido. Para que N8N reaccione a esos eventos en el momento en que ocurren, el camino más común es el webhook. En esta guía veremos cómo funciona, cómo configurarlo con seguridad y qué cuidados evitan dolores de cabeza en producción.

¿Qué es un webhook?

Un webhook es una dirección HTTP que espera ser llamada. En lugar de que N8N pregunte cada pocos minutos si hay algo nuevo en un sistema, el propio sistema avisa a N8N en cuanto ocurre el evento, enviando los datos en una solicitud.

Esta inversión trae dos ventajas claras: la automatización reacciona en segundos y no se gastan recursos en consultas que no encuentran nada.

Enfoque	Cómo funciona	Cuándo usar
Polling	N8N consulta el sistema a intervalos fijos	El sistema de origen no ofrece webhooks
Webhook	El sistema llama a N8N cuando ocurre el evento	Siempre que el origen lo permita

Cómo funciona el nodo Webhook en N8N

El nodo Webhook es un disparador. Al agregarlo como primer nodo de un workflow, N8N genera una dirección exclusiva para ese flujo. Cada solicitud recibida en esa dirección inicia una ejecución, y el cuerpo, los encabezados y los parámetros de la solicitud quedan disponibles para los siguientes nodos.

Las principales opciones del nodo son:

• Método HTTP: GET, POST, PUT, PATCH, DELETE o HEAD. La mayoría de las integraciones envía POST.
• Ruta: el final de la dirección. Una ruta legible, como pedidos-tienda, facilita el mantenimiento.
• Autenticación: ninguna, Basic Auth, Header Auth o JWT.
• Respuesta: cuándo y qué devolver a quien llamó.

URL de prueba y URL de producción

Este es el punto que más confunde a quien está empezando. Cada nodo Webhook tiene dos direcciones.

La URL de prueba funciona solo mientras haces clic en escuchar evento de prueba en el editor. Recibe una única llamada y muestra los datos en pantalla, lo que es ideal para armar el flujo con datos reales.

La URL de producción solo responde cuando el workflow está activo. Es la que debe registrarse en el sistema de origen. Si el sistema está configurado con la URL de prueba, las llamadas fallarán en cuanto cierres el editor.

Una regla simple evita el problema: usa la URL de prueba para desarrollar y cámbiala por la de producción antes de activar el workflow.

Cómo proteger tu webhook

Un webhook es una dirección pública. Cualquier persona que descubra la URL puede llamarla, así que conviene adoptar al menos una capa de protección.

Autenticación por encabezado

La opción Header Auth exige que la solicitud traiga un encabezado con un valor secreto. Es la forma más simple y funciona con casi todos los sistemas que permiten configurar encabezados personalizados.

Verificación de firma

Las plataformas de pago y de mensajería suelen firmar cada solicitud con un secreto compartido. En ese caso, conviene validar la firma al inicio del flujo, con un nodo Code o Crypto, e interrumpir la ejecución si no coincide.

Otros cuidados

• Usa siempre HTTPS. Los datos viajan cifrados y la dirección no queda expuesta en la red.
• Evita rutas obvias. Una ruta aleatoria no sustituye la autenticación, pero reduce llamadas no deseadas.
• Valida los datos recibidos. Comprueba que los campos esperados existan antes de guardar cualquier cosa.
• Limita el tamaño. N8N rechaza cuerpos por encima del límite definido en N8N_PAYLOAD_SIZE_MAX, que por defecto es de 16 MB.

Cómo responder a quien llamó

Todo webhook devuelve una respuesta HTTP. N8N ofrece tres modos:

1. Inmediatamente: devuelve un código 200 en cuanto recibe la llamada, antes de ejecutar el flujo. Es lo ideal cuando el origen solo necesita saber que el evento llegó.
2. Cuando el último nodo termina: espera a que el flujo acabe y devuelve los datos del último nodo. Útil para flujos cortos que calculan algo.
3. Usando el nodo Respond to Webhook: tú decides en qué punto del flujo responder y qué enviar, incluidos el código de estado y los encabezados.

Muchos sistemas desisten de la llamada tras unos segundos y lo intentan de nuevo. Si tu flujo es largo, responde de inmediato y procesa después. Así evitas ejecuciones duplicadas causadas por nuevos intentos del origen.

Cómo tratar llamadas duplicadas

Incluso con una respuesta rápida, el origen puede reenviar el mismo evento. Para que eso no genere pedidos o cobros duplicados, trata cada evento como algo que puede llegar más de una vez.

La técnica más común es guardar el identificador de cada evento procesado y comprobar, al inicio del flujo, si ya fue visto. Si ya lo fue, la ejecución termina sin efecto. Los sistemas así se llaman idempotentes.

Ejemplo: nuevo pedido de la tienda online

Imagina una tienda que necesita avisar al equipo y registrar cada pedido aprobado:

1. La plataforma de la tienda llama al webhook de producción con los datos del pedido.
2. El flujo valida el encabezado secreto y responde de inmediato.
3. Un nodo IF comprueba si el estado es aprobado.
4. El pedido se guarda en una hoja de cálculo o base de datos.
5. El equipo recibe un mensaje con el resumen del pedido.

Este flujo se arma en pocos minutos y sustituye la revisión manual de pedidos a lo largo del día.

Los webhooks necesitan una instancia siempre activa

Un webhook solo funciona si N8N está disponible en el instante en que ocurre el evento. Si la instancia está caída, la llamada falla y, según el origen, el evento se pierde.

Por eso, quien depende de webhooks necesita una instancia estable, con HTTPS configurado y dirección fija. Con lui, cada cliente tiene una instancia dedicada de N8N con dirección propia y HTTPS, lista para recibir webhooks desde el primer día.

Conclusión

Los webhooks son la forma más rápida y eficiente de conectar N8N con los sistemas que ya usas. Recuerda usar la URL de producción, proteger el endpoint, responder rápido y tratar los eventos duplicados. Con estos cuidados, tus automatizaciones reaccionan en segundos y con seguridad.