Manual Approvals with Wait Node Webhooks

Hello! Welcome to the next lesson in your n8n journey.

In our last session, we explored how to use the Wait node to pause a workflow for a fixed duration. This is perfect for managing rate limits or waiting for slow services. Today, we will unlock a far more dynamic and interactive capability of the Wait node, which is central to building robust, human-centric automations.

This lesson directly addresses the learning outcome: Implement a manual approval step using the Wait node with a webhook resume URL. You'll learn the architectural pattern known as "Human-in-the-Loop" (HITL), which allows you to pause a workflow indefinitely until a person or another system gives it the green light to continue. This is a critical skill for creating automations that are safe, reliable, and can handle tasks requiring human judgment.

1. What is a "Human-in-the-Loop" (HITL) Workflow?

Before diving into the mechanics, let's establish the concept. A "Human-in-the-Loop" workflow is one where an automated process deliberately pauses at a critical juncture to seek input, feedback, or approval from a person. This ensures that you maintain oversight and quality control, which is especially important when AI is generating content or a workflow is about to take an irreversible action.

n8n has some built-in nodes that provide a simplified HITL experience. To see what that looks like, the following video offers a good introduction.

As you saw, these built-in nodes are convenient for simple cases. However, they can be restrictive. The pattern you'll learn today, using the Wait node with a webhook, gives you complete control over the user experience and allows for much more complex and seamless integrations, avoiding the need for the user to open a separate browser tab to submit their feedback.

2. The Core Mechanism: Wait Node + Webhook Resume

The foundation of any custom approval flow is the Wait node configured in a special mode. Let's break down the architecture.

To summarize the key points from the article, the pattern works as follows:

1. Pause: You insert a Wait node into your workflow at the point where you need approval. Instead of setting it to "After Time Interval," you set its Resume mode to On Webhook Call.

2. Generate URL: When the workflow execution hits this node, it pauses and generates a unique, temporary webhook URL. This URL is specifically tied to this single execution. It's accessible within the workflow via the variable $execution.resumeUrl.

3. Notify: Your workflow then sends this resume URL to the approver. This could be inside an email, a Slack message, or, as we'll see, as buttons in a Telegram message. For example, you might construct two links:

   • Approve: {{ $execution.resumeUrl }}?decision=approve
   • Reject: {{ $execution.resumeUrl }}?decision=reject

4. Wait: The workflow now waits indefinitely (or until a configured timeout). Its state is saved to your database, so it can wait for hours or days without consuming server resources.

5. Resume: When the user clicks one of the links, their browser makes an HTTP GET request to the unique resume URL. The Wait node receives this call, captures any query parameters (like decision=approve), and the workflow resumes execution right where it left off. The data from the webhook call becomes the output of the Wait node, available for the next nodes to use.

This separation of concerns is powerful. One workflow can pause itself, and a completely separate process—even just a user clicking a link—can resume it.

3. A Practical Implementation with Two Workflows

Now, let's see how this architecture is implemented in a sophisticated, real-world example. The following video demonstrates a system where one workflow generates content and asks for approval via Telegram, and a second workflow listens for the user's response to resume the first one.

This approach is highly flexible and aligns well with your background in software development, as it mirrors event-driven, decoupled services.

As you saw, the magic happens when the handle approval events workflow makes an HTTP Request to the resumeUrl of the main workflow. This cleanly decouples the "waiting" logic from the "approving" logic.

Test your understanding!

In the two-workflow pattern shown in the video, Workflow A is paused at a Wait node. A user clicks "Approve" in a Telegram message sent by Workflow A.

What is the sequence of events that leads to Workflow A resuming?

Show answer

1. The Telegram button click is a "callback query" event.
2. Workflow B, which is triggered by Telegram callback queries, starts executing.
3. Workflow B processes the event data, determining which execution to resume and what the decision was ("approve").
4. Workflow B uses an HTTP Request node to make a call to the unique resumeUrl that was generated by Workflow A. It passes the approval data in the request.
5. The Wait node in Workflow A receives the HTTP request, and the workflow resumes, using the data from the request as its output.

4. Security: Hardening Your Approval Webhooks

Since the resumeUrl is a public-facing URL that can trigger actions in your system, securing it is not optional; it's a requirement for any production workflow. As a developer, you know that any unauthenticated endpoint is a potential vulnerability.

The same video provides excellent, practical advice on how to secure this endpoint.

The two key security practices are:

1. Add a Webhook Suffix: Appending a long, random string (like a UUID) to the resume URL makes it impossible for an attacker to guess or "enumerate" execution IDs to find active workflows.
2. Use Authentication: The Wait node's webhook can be configured to require authentication, such as a static secret token sent in an HTTP header (Header Auth). The workflow that calls the resume URL must then provide this secret, ensuring that only your own trusted workflows can resume executions.

5. A Written Alternative

To reinforce these concepts, here is a blog post that walks through a similar HITL workflow in writing. It provides another perspective on building the approval URLs and handling the response.

This guide illustrates the same fundamental pattern. One small detail to note is that its example URL construction uses executionId={{ $workflow.id }}. This is slightly incorrect; to get the dynamic ID for the current run, you should use {{ $execution.id }}. However, the overall principle of passing an identifier to a second workflow that then resumes the first is perfectly illustrated.

Conclusion

You have now learned one of the most powerful and flexible patterns in n8n. By moving beyond fixed-time delays and embracing dynamic, webhook-driven pauses, you can build automations that intelligently collaborate with human users.

Key Takeaways:

• The Wait node's On Webhook Call mode is the key to building custom manual approval flows.
• This pattern typically involves two workflows: a main workflow that pauses, and a listener workflow that receives the approval signal and calls the resume URL.
• The $execution.resumeUrl variable provides the unique, single-use URL to resume a specific workflow execution.
• Data can be passed back to the waiting workflow via query parameters or the request body of the resume call.
• Securing your resume webhooks with an unpredictable suffix and authentication is essential for production use.

In this module, we've focused on advanced methods for controlling the flow of your workflows. In the next module, we'll turn our attention to what happens when things go wrong. We will begin by learning how to interpret error messages to identify common workflow failure points, the first step in building resilient and debuggable automations.