Handling intermittent webhook payload formatting issues with dynamic JSON mapping in n8n

Questions
1

Hi everyone,

I am running into a bit of a logic bottleneck with an automation workflow (similar to the workflow automation guides we share on cloudstream

) and wanted to see how others handle messy incoming webhook data.

The Scenario:

I have an external service sending data via webhook to trigger an n8n workflow. However, the incoming JSON payload structure occasionally changes depending on the event type—sometimes keys are nested, and other times they are returned as flat arrays.

What I’ve Tried:

I am currently using standard IF nodes and a Code node running JavaScript to check for the existence of keys before mapping them to subsequent HTTP Request nodes. But when a schema shift happens unexpectedly, it causes downstream execution errors.

Has anyone built a clean, resilient pattern for normalizing fluctuating webhook schemas inside n8n before passing the data to downstream apps? Are you using specific error-handling sub-workflows or advanced expression parsing?

Appreciate any insights or best practices you can share!

2

Hi @Maaz Welcome!
The resilient pattern is to stop branching on the raw payload and normalize it once, in a single Code node right after the Webhook, into a fixed schema every downstream node can rely on. Coerce the shape and read keys defensively there, so a schema shift only ever touches that one node instead of breaking the HTTP Request nodes:

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,
  }
}));

The ?. and ?? are the part that buys the resilience: they read nested or missing keys without throwing, so a moved or absent field becomes null instead of a hard error. From there, route on the normalized type with a Switch node rather than chained IFs (each branch still emitting the same fields), set On Error to Continue (using error output) on the HTTP Request nodes so one bad item goes to an error branch instead of stopping the run, and point the workflow at a dedicated Error Trigger workflow under Options > Settings so anything that still slips through gets caught and alerted.