Webhook node ignores pinned data and starts listening instead

Questions
1

When I pin data on a Webhook node and then click “Execute Workflow” or “Execute step” on a downstream node, the Webhook goes into “Listening for test event” mode instead of using the pinned data.
The pinned data banner (“This data is pinned for test executions”) is visible in the OUTPUT panel, but it is completely ignored during execution.
This makes it impossible to iterate on downstream nodes without sending a real webhook call every time.

Steps to reproduce

  1. Create a workflow with a Webhook trigger (GET method)
  2. Send a test request to populate the Webhook output
  3. Pin the output data on the Webhook node
  4. Close the Webhook node
  5. Click “Execute Workflow” or “Execute step” on a downstream node (e.g. Edit Fields)
  6. Expected: the pinned data is used and downstream nodes execute
  7. Actual: the Webhook enters “Listening for test event” mode and waits for a new request

Information on your n8n setup

  • n8n version: 2.12.2 (Latest Beta) — also reproduced on 2.11.4
  • Running n8n via: n8n Cloud
  • Operating system: macOS
2

Hi @Clement_Lefebvre Welcome!
I guess if you want to test downstream nodes using the data from the before node you could just pin that data? And for that first disconnect the node and execute that node only by execute workflow node if that is a trigger so you can get the data you want to use and just select that node and press P and that should pin the data of that node, and also you can just Execute your complete workflow even if that gives an error but you would get the data from the webhook which you need, for this do not use “Execute step” or “Listen for test event” from within the webhook node triggers listening mode instead of using pinned data

3

Pinned data only works for regular nodes in test executions. Trigger nodes are the annoying exception: when you run the workflow from a Webhook trigger, n8n still re-enters listening mode because the trigger itself is responsible for producing the execution input.

A practical workaround is: capture one webhook sample, then pin the data on the FIRST downstream node after the Webhook (or duplicate the payload into a Set/Edit Fields node and pin that). From there, execute downstream nodes from that pinned node instead of from the Webhook.

So short version: what you are seeing is expected current behavior for Webhook triggers, not you misusing pinned data. If you want, share your workflow shape and I can suggest the cleanest debug setup for iterating without resending the webhook every time.

4

this sounds like it might be a regression in 2.12.2 beta — pinned data on webhook nodes works correctly in stable 2.11.4, so worth testing there first to confirm. if it only breaks in beta, filing a GitHub issue would be the right call.

in the meantime: the cleanest workaround is to pin data on the first downstream node instead of the webhook trigger itself. that way downstream execution uses pinned data regardless of the webhook listening state.