Publica un webhook trigger en n8n: de la URL de prueba a resolver los 404
Cómo pasar un webhook trigger de n8n de la URL de prueba a una URL de producción, con pasos ordenados y una ruta de diagnóstico para los errores 404.
Comprobado con las fuentes citadas el .
Objetivo y requisitos previos
Ya tienes un flujo que empieza con un nodo Webhook y funciona cuando pulsas Listen for test event. Ahora un servicio externo necesita llamarlo de verdad. Este tutorial lleva un webhook trigger de n8n desde la URL de prueba, que solo sirve en el editor, hasta una URL de producción que puedes compartir, y después recorre las comprobaciones que hay que hacer cuando esa URL de producción responde con un 404 diciendo que el webhook no está registrado.
Para seguirlo necesitas una instancia de n8n donde puedas publicar flujos, un nodo Webhook con un método HTTP y una ruta que controles, y una forma de enviar peticiones. La documentación de n8n muestra curl como la manera manual de llamar a una URL de webhook, usando el método que tenga configurado el nodo; el nodo HTTP Request en un segundo flujo funciona igual de bien. Una URL de prueba solo responde si antes ejecutas el flujo.
Cada nodo Webhook expone dos URLs, la de prueba y la de producción, mostradas en la parte superior del panel del nodo con un conmutador entre ellas. Se comportan de forma distinta a propósito, y la mayoría de los problemas con los webhooks de n8n vienen de tratar una como si fuera la otra.
| Tipo de URL | Se registra con | Escucha durante | Dónde aparecen los datos |
|---|---|---|---|
| Prueba | Listen for test event o ejecutar un flujo sin publicar | 120 segundos | En el lienzo del editor |
| Producción | Publicar el flujo | Hasta que se despublica el flujo | Pestaña Executions |
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs
Pasos para publicar un webhook trigger en n8n
Recorre los pasos en orden para poner en marcha tu webhook trigger de n8n. Cada uno elimina una causa habitual de fallo en las llamadas de producción antes de que llegues a compartir la URL.
- Construye con la Test URL: pulsa Listen for test event, envía tu petición y lee los datos entrantes en el lienzo. El escuchador permanece abierto 120 segundos, así que vuelve a activarlo si tu petición tarda en llegar.
- Fija una ruta estable y el método HTTP exacto que usará quien llame, en lugar de mantener la ruta aleatoria por defecto.
- Guarda el flujo y publícalo. La recomendación de n8n para producción es pasar a la Production URL solo cuando el flujo está guardado y publicado.
- Envía la misma petición otra vez, esta vez a la URL de producción, y confirma la respuesta esperada con curl.
- Abre la pestaña Executions y confirma que la ejecución aparece ahí, ya que los datos de producción no se muestran en el editor.
El campo Path toma por defecto un valor generado al azar para que los nodos nuevos no choquen con los existentes. Sustitúyelo pronto por una ruta deliberada y estable, opcionalmente con parámetros de ruta, para que la URL que entregas a un servicio externo sobreviva a una reconstrucción del nodo. Haz coincidir también el método HTTP exactamente: por defecto el nodo acepta un único método, y Allow Multiple HTTP Methods en Settings del nodo añade más, con GET y POST por defecto.
Una vez publicado, el webhook de producción escucha hasta que despublicas el flujo. En n8n autoalojado también puedes publicar desde la CLI del servidor por ID de flujo; ten en cuenta que n8n 2.0 sustituyó el conmutador activo/inactivo por publicar y despublicar, y que los cambios por CLI requieren reiniciar n8n para surtir efecto.
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Use the command line | Deploy | n8n Docs
Cómo leer un 404 "webhook not registered"
El cuerpo del error es más útil de lo que parece. En un caso reportado de n8n Cloud Starter, abierto como issue en GitHub en abril de 2026 sobre n8n 2.13.4, un webhook trigger de producción devolvía un cuerpo 404 nombrando el método y la ruta que no estaban registrados, mientras la URL de prueba seguía funcionando. La misma respuesta incluye la pista del propio n8n: el flujo debe estar activo para que una URL de producción se ejecute, y las llamadas de producción aparecen solo en la lista de ejecuciones. Esas son las dos primeras comprobaciones.
Después revisa la propia URL. n8n construye las URLs de webhook a partir de rutas de endpoint configurables, donde N8N_ENDPOINT_WEBHOOK vale por defecto webhook y N8N_ENDPOINT_WEBHOOK_TEST vale por defecto webhook-test. Una petición enviada a la ruta de prueba no coincidirá con un webhook de producción publicado, y viceversa. Confirma también que nada más ocupa la misma combinación: n8n permite solo un webhook por ruta y método HTTP, así que un conflicto implica despublicar el otro flujo o cambiar tu ruta o tu método.
Orden de diagnóstico para un 404 en un webhook de producción
- Lee el cuerpo: Anota el método y la ruta que n8n dice que no están registrados, y su pista de que el flujo debe estar activo.
- Confirma la publicación: Comprueba que el flujo está guardado y publicado, no solo guardado.
- Revisa el segmento de ruta: Asegúrate de que la URL usa la ruta de endpoint de webhook de producción y no la de prueba.
- Busca un conflicto: Solo un webhook puede ocupar una combinación dada de ruta y método HTTP.
- Reconstruye el registro: Despublica y vuelve a publicar, o reinicia la instancia en autoalojado, como apaños reportados.
Si la configuración parece correcta, puede que falte el registro en sí. Un informe de autoalojamiento presentado en julio de 2026 sobre n8n 2.29.8 en Docker con PostgreSQL 16 describe activar un flujo mediante la API pública, recibir un 200 con active a true y aun así obtener un 404 porque el webhook de producción no se había registrado en el servicio de webhooks en memoria de n8n. Los apaños del autor fueron reiniciar el contenedor de n8n, o desactivar y reactivar el flujo para reconstruir ese estado. Ambos casos son incidencias individuales de usuarios en versiones concretas, no comportamiento documentado ni tasas de fallo medidas, así que trátalos como cosas que probar y no como resultados esperados.
Una distinción más ahorra tiempo: si has restringido a quienes llaman con una lista de IPs permitidas, una dirección fuera de ella recibe un 403, no un 404. Un 403 apunta a las reglas de acceso; un 404 apunta al registro.
Sources: Webhook | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Endpoints | Deploy | n8n Docs, All production webhook URLs return 404 "not registered" on n8n Cloud (Starter) · Issue #27976 · n8n-io/n8n · GitHub, Active workflow production webhook URL not registered after activate API call · Issue #34038 · n8n-io/n8n · GitHub
Sorpresas propias de producción y endurecimiento
Algunos problemas solo aparecen cuando un cliente real llama a tu webhook trigger de n8n. Detrás de un proxy inverso, N8N_WEBHOOK_URL fija la URL base tanto para los webhooks de prueba como los de producción; WEBHOOK_URL está obsoleta desde n8n 2.35.0 y registra un aviso de obsolescencia. Si quienes están en la lista de permitidos no pueden conectar, n8n aconseja comprobar si hay un proxy inverso y fijar N8N_PROXY_HOPS al número de proxies por detrás de los cuales está n8n. En n8n Cloud, Cloudflare hace fallar una petición con un estado 524 si el webhook no responde en 100 segundos, así que los trabajos largos necesitan un patrón de inicio más sondeo repartido en dos webhooks.
Para un nodo Webhook en localhost en una instancia autoalojada, n8n documenta ejecutar n8n en modo túnel para que quienes llamen desde fuera puedan alcanzarlo. La página de instalación con Docker, estable 2.39.8 en el momento de la consulta, documenta un túnel cloudflared de pila completa que arranca n8n y cloudflared juntos e imprime la URL del túnel al iniciar; para instalaciones con npm, una variante solo de servicios arranca cloudflared por separado y escribe la URL base del webhook y un valor de proxy hops en un .env que n8n lee, aunque sigue requiriendo Docker para cloudflared, y las instalaciones basadas en npm están obsoletas desde n8n 3.0. La documentación califica los túneles como una comodidad de desarrollo local, no algo para usar como URL de producción.
Antes de publicar una URL que pretendes compartir, endurécela. Repasa esta lista una vez por cada webhook.
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Endpoints | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs, Install with Docker | Deploy | n8n Docs, Install with npm | Deploy | n8n Docs
