Qué es n8n y el webhook muerto que nos costó 6 días

Durante unos seis días, una cuenta de WhatsApp de un cliente dejó de recibir mensajes. Es una cuenta que mueve entre 100 y 170 al día. Meta decía que todo estaba bien: suscripción exitosa, número conectado, calidad verde. Y Meta no reenvía lo que no pudo entregar: esos mensajes no volvieron. La causa fue un webhook de n8n que ya nadie usaba, pero seguía registrado.

n8n es una herramienta para automatizar procesos uniendo aplicaciones entre sí: llega un mensaje, se crea un contacto en el CRM, se avisa por correo, se agenda una tarea. Todo con bloques que se conectan en pantalla, sin escribir un programa entero. Es de código abierto, se puede instalar en un servidor propio o usar en su versión en la nube, y por eso se volvió la alternativa favorita a Zapier y Make para quien quiere control y no pagar por cada tarea ejecutada.

Hasta ahí, la definición. Lo que casi ningún tutorial cuenta es lo que pasa cuando un flujo de n8n deja de usarse pero sigue conectado a algo. Eso fue lo que nos pasó.

Para qué sirve n8n, en concreto

n8n trabaja con flujos: una cadena de pasos que arranca con un disparador y termina en una o varias acciones. Los disparadores más usados son:

• Un webhook: una dirección web que recibe datos cuando otro sistema los manda. Por ejemplo, Meta avisando que llegó un mensaje de WhatsApp.
• Un horario: correr algo cada hora, cada mañana o el primer día del mes.
• Un evento de otra app: un formulario nuevo, una fila agregada a una hoja de cálculo, un correo recibido.

Después vienen los pasos: filtrar, transformar datos, llamar a una API, consultar un modelo de IA, escribir en una base de datos. Un flujo típico de una pyme: llega un lead del formulario → se crea en el CRM → se le manda un WhatsApp de bienvenida → se le avisa al vendedor.

La gracia frente a escribir código es la velocidad: un flujo así se arma en una tarde. El riesgo es el mismo que el de cualquier cosa que se arma en una tarde: queda andando, nadie lo documenta y, meses después, nadie recuerda que existe.

El webhook que seguía conectado

Nuestro caso. Todas las cuentas de WhatsApp Business API que operamos cuelgan de una misma app de Meta. Esa app tiene una dirección de entrega global: el lugar adonde Meta manda los mensajes si nadie le dice otra cosa. Esa dirección apuntaba a un router de n8n que ya no se usaba y que respondía con error.

Para que eso no importe, cada cuenta de cliente se suscribe con su propia dirección de entrega, que manda sobre la global. Mientras esa dirección propia esté puesta, el router muerto no recibe nada. El problema aparece el día que alguien re-suscribe una cuenta y olvida poner la dirección propia.

Nos pasó dos veces. La segunda, la suscripción de una cuenta se perdió el 30 de septiembre. El 5 de octubre se re-suscribió sin la dirección propia, y la cuenta siguió sin recibir nada, porque todo iba al n8n muerto. Lo que vimos durante esos días:

• Meta respondió success: true a la suscripción.
• El número figuraba como conectado y con calidad verde.
• El bot estaba encendido y sano.
• No llegó un solo mensaje.

Se arregló el 6 de octubre. Fueron unos seis días sin recibir lo que escribían los clientes de una cuenta que mueve entre 100 y 170 mensajes al día, y Meta no reenvía lo que no pudo entregar: esos mensajes no vuelven.

La lección no es "no uses n8n"

n8n no tuvo la culpa. La culpa la tuvo una dirección que apuntaba a un flujo que ya nadie mantenía, y un sistema que confirmaba con un "éxito" algo que no estaba funcionando. Las reglas que nos quedaron sirven para n8n, Make, Zapier o cualquier automatización:

1. Un flujo que se apaga, se desconecta. Si un webhook deja de usarse, hay que quitarlo de todos los lugares donde está registrado, no solo apagar el flujo. Un webhook muerto que sigue registrado es un agujero negro.
2. Un "éxito" de la API no prueba que llegue nada. La prueba es ver un mensaje real entrando. Lo contamos con más detalle en un 200 no prueba que la integración funciona.
3. Vigila la ausencia, no solo los errores. Ningún sistema dio error en esos seis días. Lo que delataba el problema era el silencio: cero mensajes entrantes en una cuenta que nunca tiene cero.
4. Lleva un inventario de lo que corre. En agosto de 2026, un documento interno daba por instalado un n8n propio en nuestro servidor. Lo auditamos: no existía. Si no sabes qué tienes instalado, tampoco sabes qué está conectado a qué.

¿n8n en la nube o en tu propio servidor?

La versión en la nube cobra por ejecuciones y te ahorra mantener el servidor. La instalada en tu servidor no cobra por uso, pero alguien tiene que actualizarla, respaldarla y vigilar que esté viva. Para una pyme sin equipo técnico, la nube suele ser la decisión sensata; para una empresa que ya tiene servidores y alguien que los cuida, la propia sale más barata a volumen.

En nuestra operación, la mayoría de las automatizaciones de WhatsApp terminaron como código propio y no como flujos visuales, justamente porque es más fácil vigilarlas y versionarlas. Si quieres ver cómo se conecta WhatsApp sin depender de un webhook frágil, está explicado en nuestra página de WhatsApp Business API.