Tratando problemas intermitentes de formatação de payload webhook com mapeamento JSON dinâmico no n8n

Perguntas
1

Oi pessoal,

Estou enfrentando um gargalo de lógica com um fluxo de automação (similar aos guias de automação de fluxo que compartilhamos no cloudstream) e gostaria de saber como outros lidam com dados de webhook confusos chegando.

O Cenário:

Tenho um serviço externo enviando dados via webhook para disparar um fluxo de trabalho n8n. No entanto, a estrutura da carga JSON recebida ocasionalmente muda dependendo do tipo de evento — às vezes as chaves são aninhadas e outras vezes são retornadas como arrays simples.

O Que Já Tentei:

Atualmente estou usando nós IF padrão e um nó Code executando JavaScript para verificar a existência de chaves antes de mapeá-las para nós HTTP Request subsequentes. Mas quando uma mudança de schema acontece inesperadamente, causa erros de execução nos nós posteriores.

Alguém já construiu um padrão limpo e resiliente para normalizar esquemas de webhook flutuantes dentro de n8n antes de passar os dados para aplicativos posteriores? Vocês estão usando sub-fluxos específicos de tratamento de erros ou análise de expressão avançada?

Agradeço qualquer insight ou boas práticas que possam compartilhar!

2

Oi @Maaz Bem-vindo!
O padrão resiliente é parar de fazer branches com base no payload bruto e normalizá-lo uma única vez, em um único nó Code logo após o Webhook, em um schema fixo que todos os nós downstream possam usar. Coerça a forma e leia as chaves defensivamente lá, para que uma mudança de schema toque apenas esse nó em vez de quebrar os nós 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,
  }
}));

O ?. e ?? são a parte que compra a resiliência: eles leem chaves aninhadas ou ausentes sem lançar exceções, para que um campo movido ou ausente se torne null em vez de um erro grave. A partir daí, faça o roteamento no tipo normalizado com um nó Switch em vez de IFs encadeados (cada branch ainda emitindo os mesmos campos), defina On Error como Continue (usando a saída de erro) nos nós HTTP Request para que um item ruim vá para um branch de erro em vez de parar a execução, e aponte o workflow para um workflow Error Trigger dedicado em Options > Settings para que qualquer coisa que ainda escape seja capturada e alertada.