How to use data pinning in n8n?

Data pinning in n8n lets you freeze the output data of a node so it always uses that saved output during testing, instead of re‑running the node. You simply run the node once, click the little “pin” icon in the node’s output panel, and n8n stores that result. While pinned, the node will never execute again during manual workflow testing — it will just replay the pinned data. This is extremely useful for testing downstream logic without hitting external APIs repeatedly.

 

What Data Pinning Actually Does

 

Data pinning is n8n’s way of letting you stabilize your test environment. When you pin a node:

• n8n saves the exact JSON output shown for that node.
• When you run the workflow manually, the pinned node is skipped — it will not make API calls, database queries, or execute any logic.
• Downstream nodes receive the pinned JSON as if the node just executed normally.
• Pinning affects manual executions only; production/triggered executions ignore pins and run all nodes normally.

This helps you test transforms, mappings, conditions, and expressions without waiting on — or burning through — external API calls.

 

How to Use It (Step-by-Step)

 

Here is the real workflow you follow in n8n:

• Open your workflow and run the node you want to pin. It must have real data in the output panel first.
• In the right panel where the JSON output appears, look for the small pin icon next to "Output". Click it.
• n8n will highlight the output area to show that it's now pinned.
• Now run the whole workflow manually. The pinned node will show a lightning-bolt icon indicating it was skipped, and the output will be taken from the saved pinned data.
• If you want the node to run again (for example, to call the real API): unpin by clicking the same pin icon again.

 

When You Should Use Pinning (Real Production‑Focused Advice)

 

Pinning is something you use during development and debugging, not live runs. In real teams we use it for:

• Testing expressions and data mapping from a heavy or slow API node.
• Developing downstream logic while an external system is temporarily offline.
• Avoiding rate limits on APIs like HubSpot, Google Sheets, or Stripe.
• Mocking predictable data when debugging branching logic (IF nodes, Switch, etc.).
• Safely building a long workflow from the middle outward.

Because production executions ignore pins, you can safely keep pinned nodes in your workflow during development, but remember to unpin before committing if the data matters for anyone else who opens the workflow later.

 

Important Limitations and Pitfalls

 

• Pinned data is static. If your schema changes, your test data may become misleading.
• Pinned nodes never execute during manual runs — even if their credentials change or their API would normally error.
• Pinning hides real‑world issues (auth failures, pagination quirks, null fields). Don't rely on it for too long.
• The pin only affects manual runs. Regular trigger runs (webhook, cron, etc.) ignore pinned data completely.

 

Quick Example

 

Say you have a workflow starting with an HTTP Request node hitting an API like:

{
  "id": 123,
  "email": "[email protected]",
  "plan": "premium"
}

If you pin this node, every downstream test run will always get this exact JSON — useful when you’re building conditional logic like:

{{ $json.plan === "premium" }}

You can test the conditions without hitting the API over and over.

 

The Mental Model

 

Think of data pinning as taking a snapshot of a node’s output so you can build and test calmly. It’s not a production feature — just a development convenience. It makes n8n debugging dramatically faster and protects you from unnecessary external calls while refining your workflow logic.