Allow tagging workflows through external API [GOT CREATED]

The idea is:

Using POST on the external API’s /workflow endpoint or PUT or PATCH on the /workflow/${id} one should accept a tags array. The tags array should accept an array of tag names. If a tag by the given name does not exist, it should be created on the fly.

My use case:

I’m using Git to version my workflows. I’ve used the external API to export them from my local instance for versioning, but then on the way back I want to be able to restore a specific version, or to “promote” a specific version up to our cloud instance. In these scenarios, I want to tag those workflows to match the Git tag I’ve used in the repo.

I’ve tried using the internal API (as described here Set Workflow Tags via API), but this is unsupported and I’m facing a weird problem when updating the workflow using PATCH rest/workflows/{id}

I’m getting an error that reads:

400  'Your most recent changes may be lost, because someone else just updated this workflow. Open this workflow in a new tab to see those new updates.'

I think it would be beneficial to add this because:

It would allow developers to better manage their SDLC and be able to import different concurrent versions of a workflow, provided that they’re properly tagged.

It would also bring the creation and update of workflows more in line with what we get from the export. I’ve had to deal with removing read-only properties which I get from the export and it feels hacky.

Any resources to support this?

I’m happy to showcase the use case and my import script during a call.

Are you willing to work on this?

Sure.

@AndrewMitchell I saw your post (Set Workflow Tags via API) on this issue.
Perhaps you’d like to vote up on this feature request?
Also, did you run into this error when trying the workaround described there?

HTTP 400 Your most recent changes may be lost, because someone else just updated this workflow. Open this workflow in a new tab to see those new updates.

So, I noticed that in the post referred above, the login for the cloud instance is different.
I’m now trying this.

POST https://api.n8n.cloud/auth/login?username=${username}&password=${passwrd}

But what I get in return is something like this.

{
  redirect: {
    url: 'https://foo.app.n8n.cloud/cloud/signin?code=xyz
  }
}

I was not sure of what to do with this, but following the behaviour of the n8n console I tried this:

GET https://foo.app.n8n.cloud/cloud/signin?code=xyz

Now, in the browser I can see that this should result in a cookie n8n-auth being set, but when I try this in code, I don’t get such cookie back. Any ideas?

@jburgers since you helped on that thread, do you think you could have a look at this?

Hey @mig82,

Don’t forget that what you are trying to do is not recommended and it is not supported. It may also be worth keeping this topic just for the feature request so things don’t get mixed up.

Hi @mig82,

Probably something changed. As @Jon says, that’s not recommended and not supported.

I have created a pull request to add that feature to the Public API: feat: Add tags operations and filter workflows by name in Public API by jburgers-chakray · Pull Request #5539 · n8n-io/n8n · GitHub

But it needs to be reviewed by n8n team.

1 Like

Hey @jburgers,

Sadly the CLA has not been signed on that PR so we are not able to do anything until that is sorted.

Hi @Jon

It’s seems to be signed, but I still have the warning.

I have closed the pull request and created a new one: feat: Add tags operations and filter workflows by name in Public API by jburgers-chakray · Pull Request #6332 · n8n-io/n8n · GitHub

I hope now is ok

2 Likes

Hey @jburgers,

I will check with the team, core changes typically take a bit longer as some of them are already roadmap items.

Someone will be in touch on the PR when the review starts

1 Like

Hi @mig82

From version 1.29.0 you can manage Tags using the Public API.

1 Like