Paired item data for item from node is unavailable. Ensure node is providing the required output.

Your expression used .item to reach back to an earlier node, and somewhere in the chain between that node and this one, a node produced output without attaching pairedItem metadata — so n8n has no way to know which of the earlier node's items produced the item you're currently on.

If you just want it working: replace .item with .first(), .last() or .all()[index]. That skips item tracing entirely. The rest of this page is for deciding which of those is actually correct, and for the case where you need .item to work.

The exact string, and why yours looks different

n8n builds this message from a template, so the wording varies with what you wrote:

Paired item data for <method> from node '<NodeName>' is unavailable.
Ensure '<NodeName>' is providing the required output.

<method> is whichever of these you used — and it is the literal text that appears:

The item index is attached to the error as context rather than being part of the message itself, so depending on where you read the error — the node's red banner, the execution log, a forum paste — you may or may not see a trailing item number. Don't treat its absence as a different error.

Check this first: is the referenced node pinned?

If the node you're reaching back to has pinned data, n8n throws a completely different message for the same underlying problem:

Using the item method doesn't work with pinned data in this scenario.
Please unpin '<NodeName>' and try again.

and in some paths simply Unpin '<NodeName>' to execute.

This is worth checking before anything else, because it's the version that hits people mid-build — you pin some test data to stop re-hitting an API, and an expression that worked five minutes ago stops working. Unpin the node and the error goes. Nothing is wrong with your expression.

Fix 1 — use a method that doesn't need item linking

This is n8n's own recommendation and it's right most of the time. Which one you want depends on what the referenced node actually returns:

• .first() — the referenced node returns exactly one item (a config lookup, a single API record, a Set node with one row). This is the common case and the one people should reach for.
• .last() — you want the most recent item, typically after a loop.
• .all()[index] — the referenced node returns several items and you can address the one you want by position.

{{ $('Get Customer').first().json.email }}

If none of those is honest — if you genuinely need the item that corresponds to this one — then you need Fix 2.

Fix 2 — make the offending node supply the link

The culprit is almost always a Code node in "Run Once for All Items" mode. In that mode you build the output array yourself, and if you don't set pairedItem, nothing downstream can trace through your node.

Two things worth knowing, both from n8n's source:

• "Run Once for Each Item" mode sets pairedItem: { item: index } for you. If your Code node runs per item, it is not the culprit. Stop looking at it.
• pairedItem accepts a bare number as shorthand — n8n normalises pairedItem: 0 to pairedItem: { item: 0 } internally. Both forms work.

So in "Run Once for All Items":

const items = $input.all();

return items.map((item, i) => ({
  json: { ...item.json, domain: item.json.email.split('@')[1] },
  pairedItem: { item: i },
}));

If your node fans out — one input item becoming several output items — point each output at the input it came from:

const out = [];
$input.all().forEach((item, i) => {
  for (const line of item.json.lines) {
    out.push({ json: line, pairedItem: { item: i } });
  }
});
return out;

n8n will also nudge you about this on its own: when a Code node returns a different number of items than it received, or any item without pairedItem, the output panel shows a hint reading "To make sure expressions after this node work, return the input items that produced each output item." That hint is not an error and is easy to scroll past, which is why most people meet it as this error instead, three nodes later.

Fix 3 — accept that some nodes can't supply it

A node that aggregates, merges, summarises or splits has genuinely destroyed the one-to-one relationship. There is no correct pairedItem for a row that was computed from forty input items. For anything downstream of such a node, .item is the wrong tool and Fix 1 is the answer, permanently.

The same failure, four other messages

This is the part that makes searching for it so frustrating: n8n's item-linking code throws five distinct messages, and it rewrites the message when the failure happens inside a Code node rather than in an expression field. So the same root cause reaches you under different text depending on where you hit it.

Two neighbours that look similar but aren't item-linking problems at all:

• Node 'X' hasn't been executed — the referenced node hasn't run yet on this execution. n8n's own hint here suggests guarding with {{ $if( $("X").isExecuted, …, "") }}.
• No data found from `main` input — the referenced node ran but produced no output on its main branch. Nothing to link to, because there's nothing there.

Why this happens at all

n8n items don't carry their history inside them. Instead every node is expected to stamp each output item with a pointer to the input item that produced it, and .item resolves by walking that chain of pointers backwards, node by node, until it reaches the node you named. One node that doesn't stamp its output breaks the chain — and the error surfaces at the node doing the reading, which may be well downstream of the node actually at fault.

That's the practical lesson: the node named in the error is the node that failed to supply the data, not the node you need to edit. Read the node name in the message and go look at that node, not at the expression in front of you.

A worked example

A lead-reply workflow I built sidesteps this error rather than fixing it. Each branch — invalid address, unusable draft, mail-server rejection, successful send — writes its own outcome row with a reason at the point the outcome is known, instead of leaving an expression further downstream to trace back which lead a given result belonged to.

Nothing in it uses .item, so nothing in it can fail to resolve .item. That is usually the cheaper answer: when a workflow needs item linking in several places, the shape of the workflow is often what's wrong, not the expression.

Sources: packages/workflow/src/workflow-data-proxy.ts and the editor's English string table in n8n's repository, read directly. n8n documents item linking in general but does not have a page for this error string.

Last verified 15 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.