n8n error index

Code node · Code

Invalid output format

An item you returned has one of n8n's reserved keys and one of your own keys at the same level. n8n refuses that combination, because it can no longer tell whether the object is an n8n item or your data.

The description under it names the key it tripped on:

An output item contains the reserved key json. To get around this, please wrap each item in an object, under a key called json.

The five reserved keys

json   binary   pairedItem   error   index

That list is exact — it's a fixed set in n8n's source, not a convention. Any other top-level key is "yours".

The rule, stated properly

At the top level of an item, it's all or nothing:

• No reserved keys? Fine. n8n wraps your whole object in json for you. return [{ name: 'Ada', role: 'admin' }] becomes { json: { name: 'Ada', role: 'admin' } }.
• Only reserved keys? Fine. That's a correctly-formed n8n item.
• A mix? Refused. This error.

So the failing shape is almost always someone who got the envelope right and then attached one extra thing to the outside of it:

// throws — 'json' is reserved, 'role' is yours
return [{ json: { name: 'Ada' }, role: 'admin' }];

// fine — role belongs inside
return [{ json: { name: 'Ada', role: 'admin' } }];

The same applies to binary. return [{ binary: { data: … }, filename: 'x.pdf' }] throws for exactly the same reason; the filename goes inside json, or inside the binary entry's own metadata.

Which key it names

n8n reports the first reserved key it encounters while walking the object's own keys, in insertion order. So an item built as { pairedItem: 0, json: {…}, note: 'x' } reports pairedItem, not json — even though json is the one you were thinking about. Don't read the named key as "the key that's wrong". Read it as "the key that proved this is meant to be an n8n item".

The one that's actually wrong is the unreserved one, and n8n doesn't name it here.

Reading the bracketed suffix

n8n appends location information when it has it:

• Invalid output format [item 4] — item 4 specifically
• … [line 12] or … [line 12, for item 4] — when a line number is known too

An item index this far into the batch usually means the shape is data-dependent: some branch of your code builds the item differently from the others.

Why n8n refuses instead of guessing

An n8n item is a plain JavaScript object, and so is your data. There's no type tag to separate them. The only signal available is which keys are present — so n8n treats the presence of any reserved key as "this object is an envelope" and the presence of a foreign key as "this object is payload". An object claiming both is genuinely ambiguous, and every possible guess is wrong some of the time.

That's also why the no-reserved-keys case gets auto-wrapped without complaint: there's no ambiguity to resolve.

Related errors

• Unknown top-level item key: <key> — the other branch of the same check. Your item has a foreign key but no reserved key of its own, while some other item in the array does. That means the array is inconsistent.
• Code doesn't return items properly — the shape check that runs before this one: the return value isn't an array of objects at all.
• A 'json' property isn't an object — the envelope is right, but the thing inside json isn't an object.

---

Source: packages/nodes-base/nodes/Code/reserved-key-found-error.ts and result-validation.ts in n8n's repository, read directly. The reserved-key list is REQUIRED_N8N_ITEM_KEYS in that file. n8n's Code node documentation does not list this error string.

Related errors on this site

• Code doesn't return items properly
• Unknown top-level item key
• A 'json' property isn't an object

Last verified 16 September 2026 against n8n 2.39.5 (source read on master @ 2.40.0). n8n changes these messages between releases; if the wording you see differs, the version above is what this page was checked against.