Unique UUID Webhook Endpoints for Each Wait Node

Hi all,

I’m building a workflow where each Wait node should pause execution and later resume via a unique webhook URL using a UUID.

The idea is:

  • My app triggers the workflow via a webhook.
  • For each Wait node, it should receive a distinct webhook URL (based on a UUID) that it can call after a user action.
  • The workflow includes multiple Wait nodes connected by Code nodes in between.

The issue:
All the Wait nodes in the same execution seem to share the same resume URL.

How can I make sure each Wait node in the same workflow execution has its own unique webhook endpoint?

The execution session can have only one waiting/resumable point. Why would having a unique url make sense?

My application interacts with a single workflow by calling its webhook endpoints.
Each step in the workflow dynamically returns the next screen and the parameters the app needs to display, guiding the user through to the next step.

But why you can’t reuse the same url to continue?

I mean, n8n will know which wait node to resume the execution at disregarding whether the resume url is the same or not.

You’ve got me rethinking things. In general, I’d prefer to avoid keeping any state in my application about the current step of a specific flow—like a registration or KYC process.

For example, imagine a user starts registration, enters their personal details, and then has to wait for a business process to verify them. Once that process is complete, I’d want to resume the flow right from where it left off.

So the question is: how do I know where to continue?

Now that I think about it, I could just manage a subflow that handles the state—tracking the user ID, the flow name, the step, and its webhook endpoint. Then, when the app starts up, I could query that subflow to check if there are any flows that were paused mid-process.

Did you try to implement any approach?
The beauty of n8n is that you can improve the workflow as you go and face challenges, split workflow, introduce subworkflows etc.