Cuando un webhook de n8n no funciona, el error puede estar antes de que n8n reciba nada, dentro del propio workflow o después, cuando intenta responder o llamar a otro servicio.
El diagnóstico correcto consiste en separar capas: URL, método, autenticación, payload, ejecución, respuesta y sistema externo. Cambiar nodos al azar suele hacer más difícil encontrar la causa.
1. Estás usando la URL equivocada
n8n suele diferenciar entre URL de prueba y URL de producción. Si el emisor llama a una URL que no corresponde al estado actual del workflow, el evento puede no llegar.
Comprueba exactamente qué URL está configurada en el servicio emisor y si el workflow está activo cuando utilizas el endpoint de producción.
2. El método HTTP no coincide
GET, POST, PUT y otros métodos no son intercambiables. Si el emisor utiliza POST y el webhook espera GET, no estás probando la misma ruta.
Revisa también content-type y cómo se envía el cuerpo. Un JSON y un formulario codificado necesitan tratamiento distinto.
3. El workflow no está activo
Un webhook de producción necesita que el workflow pueda recibir eventos en el entorno correspondiente.
No confundas una prueba manual que funciona mientras escuchas con un endpoint que debe estar disponible de forma continua.
4. El servicio emisor nunca envió el evento
Antes de culpar a n8n, comprueba logs o historial del sistema que debería disparar el webhook.
Si el proveedor permite reenviar el evento, utiliza esa función y compara fecha, código de respuesta y payload.
5. La autenticación o firma falla
Algunos webhooks incluyen tokens, headers o firmas para verificar procedencia.
Comprueba que el secreto utilizado coincide y que no estás transformando el cuerpo antes de validar una firma que depende del contenido original.
6. El payload tiene una estructura distinta
Es frecuente desarrollar con un ejemplo y recibir en producción campos opcionales, arrays o nombres distintos.
Inspecciona la ejecución y valida qué estructura llegó realmente antes de referenciar rutas profundas en expresiones.
7. Un nodo posterior falla y parece que el webhook no funciona
El evento puede haber entrado correctamente y fallar después al llamar a CRM, enviar un email o transformar datos.
Revisa la ejecución completa y localiza el primer nodo con error. El webhook solo es una parte del flujo.
8. La respuesta tarda demasiado
Algunos servicios esperan una respuesta rápida. Si tu workflow realiza muchas acciones antes de responder, el emisor puede interpretar timeout aunque n8n continúe ejecutando.
Cuando el caso lo permita, responde pronto y procesa el trabajo pesado después.
9. El mismo evento llega varias veces
Los proveedores pueden reintentar si no reciben la respuesta esperada. Esto puede producir duplicados.
Diseña idempotencia con un identificador de evento o de entidad para evitar crear dos clientes, dos pedidos o dos tareas.
10. El problema está en red o proxy
En despliegues propios, dominio, HTTPS, proxy inverso, firewall y puertos pueden afectar accesibilidad.
Verifica el endpoint desde fuera del servidor y separa un problema de red de un problema de workflow.
Cómo diagnosticarlo en orden
Empieza por el emisor: confirma que envió el evento y qué respuesta recibió. Después comprueba URL, método y headers. A continuación revisa si n8n registró ejecución. Solo entonces entra en la lógica de nodos.
Este orden evita perder tiempo corrigiendo expresiones cuando el evento nunca llegó.
Cómo trabajar con payloads reales
Guarda ejemplos anonimizados de payloads correctos e incorrectos. Utilízalos como casos de prueba cada vez que cambies el workflow.
No asumas que todos los eventos de un proveedor tienen exactamente los mismos campos. Trata opcionales y nulos de forma explícita.
Cómo responder al webhook
Decide si necesitas devolver un cuerpo concreto, un código específico o únicamente confirmar recepción.
El contrato de respuesta pertenece a la integración. Si el proveedor espera un formato, respétalo aunque internamente tu workflow utilice otra estructura.
Reintentos sin duplicar acciones
Si un servicio reenvía el mismo evento después de un timeout, tu flujo debe reconocerlo.
Almacenar un ID procesado o comprobar el estado de la entidad antes de escribir ayuda a convertir el flujo en idempotente.
Errores temporales frente a permanentes
Un 429 o un timeout puede recuperarse con reintento. Un 400 por un campo inválido probablemente necesita corrección de datos.
Tratar ambos de la misma forma crea bucles inútiles o pérdida de eventos recuperables.
Qué registrar en logs
Incluye identificador del evento, entidad afectada, hora, paso de fallo y código externo. Evita registrar secretos o datos innecesarios.
Un log útil permite responder qué pasó sin abrir manualmente veinte nodos.
Alertas accionables
No necesitas una alerta por cada detalle. Prioriza fallos que requieren una persona: credencial caducada, cola bloqueada, error permanente o volumen anómalo.
Las alertas repetitivas sin acción terminan ignorándose.
Ejemplo práctico
Un formulario externo debería crear una oportunidad en CRM, pero algunos leads desaparecen.
El historial del emisor muestra timeouts. n8n sí recibía el evento, pero respondía después de llamar al CRM y generar un documento.
El flujo se rediseña para confirmar recepción antes y continuar el proceso después, añadiendo idempotencia para evitar duplicados en los reintentos.
Errores frecuentes al arreglar webhooks
- Cambiar la URL sin revisar el emisor.
- Confundir endpoint de prueba y producción.
- No comprobar método y content-type.
- Ignorar timeouts del proveedor.
- No utilizar identificador de evento.
- Guardar secretos en logs.
- Reintentar errores permanentes sin límite.
Curso relacionado
Para profundizar en webhooks, APIs, errores e idempotencia, consulta n8n para negocios: automatización avanzada, APIs e IA en producción.
Recursos relacionados
- Webhooks de entrada y respuestas controladas
- Idempotencia: evitar duplicados
- Reintentos, rate limits y backoff
- Consumir una API con HTTP Request
- Logs, métricas y alertas útiles
- 10 errores de n8n en producción
En una integración comercial, Aira CRM puede ser el sistema de destino del lead y BlackHold Consulting puede diseñar la arquitectura de automatización. Si el evento termina en gestión administrativa, Clientum puede actuar como sistema operativo.
Preguntas frecuentes
¿Por qué funciona en test y no en producción?
Revisa URL, activación del workflow, dominio y entorno. Test y producción pueden utilizar endpoints diferentes.
¿Qué hago si llega duplicado?
Utiliza un identificador de evento o entidad y comprueba si ya fue procesado antes de ejecutar acciones.
¿Cómo sé si el problema está fuera de n8n?
Comprueba primero el historial del servicio emisor y el código HTTP que recibió.
¿Debo responder antes de terminar todo el flujo?
Depende del contrato del proveedor. Si exige respuesta rápida, puede ser mejor confirmar recepción y continuar después.
¿Qué hago con un 429?
Trátalo como un límite temporal y utiliza backoff y reintentos controlados.
Plan de diagnóstico en una hora
Primero confirma que el emisor envió el evento. Después valida URL, método y autenticación. A continuación revisa ejecución y payload. Finalmente analiza nodos posteriores y respuesta.
Si no puedes reproducir el problema, conserva ejemplos reales y añade logs temporales suficientes para localizar la próxima incidencia.
Pruebas antes de cerrar la incidencia
Envía un evento válido, uno incompleto, uno duplicado y uno con un servicio externo temporalmente caído.
Comprueba que cada caso produce una salida controlada y que los errores importantes generan una alerta útil.
Cómo evitar que vuelva a ocurrir
Documenta el contrato del webhook, campos obligatorios, autenticación, respuesta y códigos esperados. Añade pruebas de regresión y una persona responsable.
La prevención consiste en convertir el conocimiento de la incidencia en una regla, validación o alerta permanente.
Conclusión
Cuando un webhook de n8n no funciona, diagnostica de fuera hacia dentro: emisor, endpoint, autenticación, payload, ejecución y respuesta. Ese orden reduce muchísimo el tiempo de resolución.
Control adicional
Revisa también relojes y timestamps cuando el proveedor firme peticiones o limite ventanas de validez. Una diferencia de hora puede provocar fallos que parecen aleatorios. Mantén sincronización y registra el momento exacto de recepción.
Si utilizas un proxy o balanceador, confirma que no modifica headers necesarios y que transmite correctamente el cuerpo original. La capa de infraestructura debe formar parte del mapa de diagnóstico.
Control adicional
Fotografía: Jakub Zerdzicki / Pexels.