Detecting Workflow Activation Status in Custom Webhook Node During Test Runs

Questions
, ,
1

Hello n8n community,

I’m developing a custom webhook node locally to integrate with an external API.
I’m struggling to determine whether the workflow is active during test runs, which is critical for managing those actions correctly.

Current Setup and Problem:

  • The API I’m working with overwrites existing actions when a new action is submitted with the same identifier. This means that during a test run, submitting actions with a webhook test URL overwrites production actions if they exist, and canceling or finishing the test (in the delete method) deletes them. I need to detect the workflow activation status to avoid unintended overwrites or deletions and ensure production actions are handled correctly if needed.
  • My intended logic for the delete method during a test run is to re-register the actions with the n8n production URL if the workflow is active, and delete them if the workflow is not active.
  • During test runs (which use webhook test URL), I need to know if the workflow is active in production to decide whether to preserve or delete those actions. The challenge is that I can’t reliably check the workflow’s active status in this context.

Solutions Explored:

  1. Manual Reactivation: One approach is to manually unactivate and reactivate the workflow after a test run to re-establish actions, but this requires user intervention and isn’t practical for production use.
  2. File-Based State: I’ve considered using a per-workflow file to track an activation flag, updating it when the workflow is activated or deactivated, but I’m unsure how to implement this effectively.
  3. staticData: I tried using staticData to store the activation state, but I found out that it is not the same between test and production runs.

Question for the Community:

  • Is there a built-in method in n8n to detect a workflow’s activation status during test runs for a custom node?
  • Can you suggest a solution (e.g., file-based state tracking, external storage) and the best practice for managing this type of state detection in n8n to handle the API behavior and support my intended delete logic?

I’d greatly appreciate any advice, examples, or pointers to relevant discussions. Thank you!

Best,
Gil

1 Like
2

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.