Pinning a Step's Output So You Stop Re-Calling the Same API While You Debug
You can now pin a step's real output from a past run so test executions reuse it instead of hitting a live API again — pinned data is honored only in dry runs, never on a live trigger.
If you've ever fixed a small bug and had to re-run a whole workflow twenty times to test it — hitting a live CRM or billing API each time, and cleaning up twenty extra rows afterward — Workflows now has a way around that.
How pinning works
Once a step has actually run and produced real output, you can pin that output. From then on, while the pin is active, the engine skips making the real call for that step and hands the stored output downstream instead — so the rest of the workflow keeps executing normally against real data, minus the one call you've already verified.
The boundary that matters
Pinned output is only honored during dry runs and step tests — never on a live trigger. A real, production-triggered execution of the workflow always calls the actual step, every time, regardless of what's pinned. Pinning is a debugging aid, not a way to fake production data in a live run.
Why we built it this way
This is the same problem n8n's "pin data" feature solves, and for the same reason: iterative debugging against a live external API is slow and can leave side effects behind with every test run. Keeping the pin strictly out of live executions is a deliberate boundary, not an oversight — the moment a pin could silently affect a real customer-facing run, it stops being a debugging convenience and becomes a liability.
If you're mid-debug on a workflow with an expensive or side-effecting API call in it, this is the fix: run it once for real, pin the result, and iterate on everything downstream without hitting that API again.