Hey, @MutedJam ! Sorry about this late reply.
The way this node works using n8n UI is:
- User adds the Zendesk trigger (target is not yet created on Zendesk)
- User executes the node: a test target is created on Zendesk (ex. /webhook-test/35b0557d-b752-4ff0-ab10-c2605881e97a/webhook)
- User cancels the execution: the test target is removed
- User activates the workflow: a target like /webhook/35b0557d-b752-4ff0-ab10-c2605881e97a/webhook is created. Sometimes, this path is “127/zendesk trigger/webhook”. (why?)
- User clicks on “Execute workflow”. The test target is created again (ex. /webhook-test/35b0557d-b752-4ff0-ab10-c2605881e97a/webhook).
- User stops the execution: the test target is removed and only the “live” target remains.
As I wrote, I am not using the n8n UI. I created a very simple python client to deal with the NodeJS backend. This API is just getting and posting data as the UI does. This is how the API adds a node:
- API get all available nodes and there parameters
- our frontend display this options and sends a post to our API
- our API sends a PATCH to the NodeJS backend and adds the node to the workflow (so far, no target was created on Zendesk)
- Our user activates the workflow: our API updates n8n workflow and activate it. Now, I target is created on Zendesk. This is the target that vanishes after a couple of hours.
Our use case is different from others as we don’t use the n8n UI. I am afraid that I missed something here and that’s why I wanted to understand a bit more the internal details of this node.