Gestión de problemas intermitentes de formato de webhook con mapeo JSON dinámico en n8n

Preguntas
1

Hola a todos,

Estoy enfrentando un pequeño cuello de botella lógico con un flujo de trabajo de automatización y quería ver cómo otros manejan datos de webhook entrantes desordenados.

El Escenario: Tengo un servicio externo que envía datos a través de webhook para activar un flujo de trabajo en n8n. Sin embargo, la estructura de la carga útil JSON entrante ocasionalmente cambia dependiendo del tipo de evento—a veces las claves están anidadas y otras veces se devuelven como matrices planas.

Lo que he Intentado: Actualmente estoy usando nodos IF estándar y un nodo de Código que ejecuta JavaScript para verificar la existencia de claves antes de asignarlas a nodos HTTP Request posteriores. Pero cuando un cambio de esquema ocurre inesperadamente, causa errores de ejecución aguas abajo.

¿Alguien ha construido un patrón limpio y resiliente para normalizar esquemas de webhook fluctuantes dentro de n8n antes de pasar los datos a aplicaciones aguas abajo? ¿Estás usando sub-flujos de trabajo específicos de manejo de errores o análisis de expresiones avanzado?

¡Agradezco cualquier información o mejor práctica que puedan compartir!

2

¡Hola @Maaz! ¡Bienvenido!
El patrón resiliente es dejar de ramificarse en la carga útil sin procesar y normalizarla una sola vez, en un único nodo Code justo después del Webhook, en un esquema fijo en el que cada nodo posterior pueda confiar. Coerciona la forma y lee las claves defensivamente allí, de modo que un cambio de esquema solo toque ese nodo en lugar de romper los nodos HTTP Request:

const p = $json.body ?? $json;
const rows = Array.isArray(p) ? p : (Array.isArray(p.items) ? p.items : [p]);

return rows.map(r => ({
  json: {
    id:    r.id    ?? r.data?.id ?? null,
    email: r.email ?? r.data?.customer?.email ?? null,
    type:  r.event ?? r.type ?? 'unknown',
    raw:   r,
  }
}));

Los operadores ?. y ?? son lo que compra la resiliencia: leen claves anidadas o faltantes sin lanzar excepciones, por lo que un campo movido o ausente se convierte en null en lugar de un error grave. A partir de ahí, ramifica en el tipo normalizado con un nodo Switch en lugar de IF encadenados (cada rama aún emite los mismos campos), establece On Error en Continue (usando salida de error) en los nodos HTTP Request para que un elemento deficiente vaya a una rama de error en lugar de detener la ejecución, y apunta el flujo de trabajo a un flujo de trabajo Error Trigger dedicado en Options > Settings para que cualquier cosa que aún se escape sea capturada y alertada.