El webhook de n8n no funciona: lista de comprobación paso a paso para depurarlo
Una lista de comprobación práctica para aislar problemas con webhooks de n8n relacionados con los modos de URL, la publicación, los métodos HTTP, la autenticación, las respuestas y los registros de ejecución.
Comprobado con las fuentes citadas el .
Antes de empezar: registra la solicitud y el resultado esperado
Empieza con una solicitud reproducible. Registra si estás llamando a la URL de prueba o de producción, el método HTTP, el modo de autenticación seleccionado, el modo de respuesta, el estado y el cuerpo devueltos, y si aparece una ejecución en n8n. Elimina contraseñas, tokens, encabezados de autorización y otros secretos antes de compartir el registro con un mentor o grupo de taller.
Anota en términos concretos el resultado que esperabas. Por ejemplo: «Una solicitud POST debería iniciar el flujo de trabajo y devolver la salida del nodo final». Esto separa tres preguntas que es fácil confundir: ¿La solicitud llegó al webhook? ¿Se ejecutó el flujo de trabajo? ¿Recibió quien hizo la llamada la respuesta prevista?
Vuelve a enviar la misma solicitud controlada después de cada cambio. Esta secuencia es una sugerencia editorial de depuración, no un estándar obligatorio de n8n. Su propósito es ayudarte a identificar el primer ajuste que no coincide, en lugar de cambiar varias variables y perder la pista de qué solucionó el problema.
Comprobación 1: haz coincidir la URL de prueba o producción con el estado del flujo de trabajo
Primero, confirma qué URL del webhook está utilizando quien realiza la llamada. Para una solicitud de prueba, selecciona «Listen for test event» antes de enviarla. El webhook de prueba registrado permanece activo durante 120 segundos, por lo que una solicitud enviada antes de empezar a escuchar o después de ese intervalo podría no llegar al receptor temporal.
Para usarlo en producción, publica el flujo de trabajo y llama a su URL de producción. La publicación registra el webhook de producción. No interpretes la ausencia de datos de la solicitud en el lienzo del flujo de trabajo como prueba de que la producción ha fallado: allí no se muestran los datos de las solicitudes de producción. Busca en su lugar la ejecución resultante en los registros de ejecución.
La finalización de esta comprobación depende del modo previsto. En el modo de prueba, el receptor está activo cuando llega la solicitud correspondiente y los datos entrantes pueden observarse en el editor. En el modo de producción, el flujo de trabajo está publicado, quien realiza la llamada utiliza la URL de producción y tú inspeccionas la ejecución mediante Executions.
Comprobación 2: verifica el método de la solicitud HTTP
Compara el método real del remitente con el método configurado en el nodo Webhook. De forma predeterminada, un nodo Webhook acepta un único método, como GET o POST, salvo que se haya habilitado la compatibilidad con varios métodos. Una URL correcta no compensa una discrepancia de método.
Inspecciona la propia solicitud en lugar de confiar únicamente en la etiqueta de la herramienta que realiza la llamada o en tu memoria. Si es posible, conserva una versión saneada del comando o de la configuración de la solicitud. Después, verifica el ajuste del nodo Webhook y vuelve a enviar la misma solicitud con el método correspondiente.
Considera completada esta comprobación cuando el método configurado y el transmitido coincidan. Si ese cambio hace que aparezca una ejecución, registra la discrepancia antes de continuar. Las pruebas proporcionadas no incluyen una matriz completa de códigos de estado para los métodos incorrectos, así que evita tratar un código de error concreto como universal.
Sources: S3
Comprobación 3: verifica la autenticación y las credenciales configuradas
A continuación, compara la opción de autenticación del nodo Webhook con lo que envía el servicio que realiza la llamada. Las opciones documentadas son autenticación Basic, autenticación mediante Header, autenticación JWT o ninguna autenticación. El enfoque seleccionado debe coincidir con el método exigido por quien realiza la llamada o por el servicio integrado.
Comprueba cuidadosamente ambos lados. Confirma el modo de autenticación en n8n y después examina cómo proporciona la solicitud las credenciales. En los métodos basados en encabezados, verifica que quien realiza la llamada envíe el encabezado previsto sin exponer su valor en notas o capturas de pantalla. Para la autenticación Basic o JWT, comprueba que quien realiza la llamada esté configurado para esa misma categoría.
Esta lista de comprobación no puede prescribir valores de credenciales ni formatos de encabezado específicos de un servicio, porque dependen del método seleccionado y del servicio que realiza la llamada. La comprobación se completa cuando los modos coinciden y una comparación saneada no revela ningún campo de credencial ausente. Si persisten las dudas, consulta los requisitos del servicio correspondiente en lugar de probar secretos sin relación.
Sources: S4
Comprobación 4: separa la ejecución del flujo de trabajo del comportamiento de la respuesta del webhook
Un webhook puede iniciar un flujo de trabajo aunque quien realiza la llamada reciba una respuesta inesperada, vacía o demorada. Antes de concluir que el disparador ha fallado, determina si existe una ejecución. Si existe, deja de centrarte en la URL y los ajustes del disparador y dirige tu atención a la configuración de la respuesta.
Cuando el nodo Webhook está configurado para delegar su respuesta, el flujo de trabajo debe incluir un nodo Respond to Webhook. Configura el nodo Webhook para utilizar esa ruta de respuesta y asegúrate después de que el nodo de respuesta forme parte del flujo de trabajo. Si deben devolverse datos producidos por otros pasos, estructura el flujo de trabajo para que los datos previstos estén disponibles en el paso de respuesta.
Otro modo documentado responde después de que termine el último nodo. En ese modo, el webhook devuelve los datos de salida del nodo final junto con el código de respuesta. La comprobación se completa cuando puedes explicar qué nodo controla la respuesta y confirmar que el cuerpo recibido concuerda con el modo seleccionado.
Comprobación 5: inspecciona el registro de ejecución
Abre la página Overview de la instancia de n8n y selecciona la pestaña Executions. Utiliza la lista de ejecuciones para responder a la pregunta de bifurcación más útil de esta lista: ¿la solicitud controlada creó una ejecución? El acceso depende de los flujos de trabajo que tengas disponibles, y las pruebas proporcionadas no establecen el comportamiento de conservación o registro.
Si no aparece ninguna ejecución, vuelve a las comprobaciones anteriores: modo de URL, estado del receptor o de publicación, método de la solicitud y autenticación. Si aparece una ejecución, inspecciona dónde se desvió su comportamiento de lo que esperabas. En particular, una ejecución existente acompañada de una respuesta incorrecta para quien realizó la llamada apunta a la lógica del flujo de trabajo o a la configuración del modo de respuesta, en lugar de demostrar que el disparador del webhook falló.
Registra si apareció una ejecución después de cada intento controlado. Esto crea un historial de diagnóstico compacto que un mentor puede revisar sin necesitar credenciales ni contenido sensible de la solicitud.
Criterios de finalización: identifica el primer ajuste discrepante y reproduce correctamente la solicitud
Termina cuando puedas nombrar el primer ajuste discrepante y reproducir la solicitud después de corregirlo. Tu registro debe mostrar el tipo de URL, el estado del flujo de trabajo, el método HTTP, el modo de autenticación, el modo de respuesta, el estado y el cuerpo devueltos, y si apareció una ejecución. Mantén ocultos todos los valores secretos.
En el modo de prueba, una reproducción correcta significa que el receptor está activo cuando se envía la solicitud y que los datos entrantes pueden observarse en el editor. En el modo de producción, significa que el flujo de trabajo está publicado, se llama a la URL de producción y la ejecución se comprueba en Executions en lugar de esperarla en el lienzo.
Trata este orden como una rutina de diagnóstico sugerida, no como un instrumento validado ni un estándar obligatorio. Las fuentes de apoyo documentan el comportamiento de configuración de n8n, pero no demuestran que esta secuencia produzca una depuración más rápida ni mejores resultados de aprendizaje. Si se cambiaron varios ajustes a la vez, restaura una configuración controlada y modifica un solo ajuste no secreto cada vez.
Sources: S2, S1, S3, S4, S5, S6, S11
Practica el diagnóstico con un reto de n8n
Para convertir la lista de comprobación en un ejercicio práctico, crea deliberadamente una discrepancia de configuración segura en un flujo de trabajo que no sea de producción, predice si debería aparecer una ejecución y utiliza después la lista para aislarla. Esta es una actividad de aprendizaje sugerida, no una evaluación validada.
El sitio web n8n Balloon Challenges ofrece retos prácticos de automatización con pistas progresivas. Los participantes crean flujos de trabajo en su propio entorno de n8n, por lo que la responsabilidad sobre las credenciales, los datos de prueba y la ejecución segura permanece dentro de ese entorno. En el formato de evento presencial, el trabajo puede compartirse con un mentor para su verificación manual.
Cuando expliques tu diagnóstico, expón claramente las pruebas: qué solicitud enviaste, qué ajuste era diferente, si apareció una ejecución y cómo se comportó la solicitud corregida. Evita compartir secretos o afirmar que completar el ejercicio proporciona una certificación o un resultado de aprendizaje medido.
