Create new webhook on event

Is it possible to create a new webhook in response to another event?

For example:

  1. I create a new GitHub repo
  2. This triggers a workflow
  3. That workflow registers a new webhook for that GitHub repo
  4. That new webhook has it’s own n8n logic after being triggered

Yes, that would be possible but in that case, you would have to do the setup manually with an HTTP Request Node.

Docs about how a webhook can be created:

1 Like

Makes sense. It would be nice if this was something in the UI.

Like if you could feed one event into a hook and use the params to build the webhook request.

I might look into the source to try to pull this off…any pointers before I dive in?

Ah yes, that would be something which could be added, should be quite simple.

The process should be quite straight forward. The code can be found here:

The only thing you have to make sure of is to set the headers correctly like here:

1 Like

Thanks! I haven’t used Vue or setup the dev environment yet, but we will see how far I get.

Ah thought you wanted to do it with the HTTP Request Node.

If you want to add support to the Github node it would be this one:

There you can also see how other functionality got implemented. Vue experience would not be needed. The parameters can simply be defined in JSON.

Okay, but I noticed that the webhook nodes don’t have a UI piece showing you can pass data into it, so I’m just concerned there’s something hardcoded that would require UI code.

Like the bottom one has a “socket” UI line on the left side because it can take in data.

Yeah it looks like Github implements INodeType, so it shouldn’t be a problem to add input params. I’ll look.

I was worried it would inherit from a WebHook type (or something) which would not allow inputs. Looks like your code is pretty slick :wink:

Ah no a Trigger Node will never have any Inputs!

If you want to do that, you have to add it to the regular Github-Node like posted above.

Is there a way around that? I can see some really cool systems being made if a Trigger node could be “triggered”.

I can also see this making this whole thing super complex

A Trigger-Node triggers when the event occurs which got defined for it and then starts the workflow with the data it received.
And even if we would do what you propose, it would “trigger” the workflow to start and not the webhook creation. To do something like that regular nodes exist as it is a simple REST call like all the other things which can be done with the most n8n nodes. It maybe seems like it is related to the Trigger-Node but in the end, if you think about it, it is really not.

Yeah the more I think about it the more I think it would be a nightmare manage. The whole point of a system like n8n is so that you can visualize a static flowchart-like system. If the system is allowed to dynamically change itself, you loose that ability to intuitively visualize it.

I’m trying to just a trigger for changes on any of my repos, so I should probably solve that more directly than trying to dynamically great new trigger nodes. For context, I’m using n8n to automate my iOS deployments. I thought it would be more fun than Jenkins.

How many different repros do you have? Because simply having a Trigger-Node for each, as long as you do not have a hundred of them should then probably be fine.

Ah, great idea! Tell me how it goes. If you realize that some kind of node would be helpful to do that, tell me then I can think about if it would be worth adding to n8n if it could be helpful for many people.

So right now there’s a lot, like 20, but it might become 100s or 1000s later…I’m making a “build-your-own-app app” which will use GitHub. Jenkins might be a better way to go about it, but this project is already so experimental so I thought I’d have fun with n8n first.

What you could do in that case is to use the REST API the Editor-UI uses:

With it, you can simply create new workflows and activate them on the fly. In the end, is each workflow a simple JSON file.

So you could have one main workflow which does the actual work and gets its input data from a webhook and then multiple other workflows (webhook-workflows) that simply contain a webhook node and an HTTP Request Node which triggers the main workflow whenever something changes.
The webhook-workflows would be the ones you can then simply create and activate on the fly whenever a new project gets created on Github.

That sounds great! I didn’t know you had an API like this!!

Can n8n handle that many workflows though? This thing might end up creating 1,000s of them. Is there a limit?

That API is currently undocumented and was actually just meant to use by the Editor-UI. So it may change in the future. As I can see that it could be quite helpful in many cases to do something like, it is also possible that this API gets improved in the future to be easier to use for such cases.

Anyway, if something would change you would find information about it in the BREAKING-CHANGES file which you should check anyway always before you upgrade to a new version.

I have never tried to have 1,000s of workflows. How many are possible depends then mainly on your hardware. It also depends a lot on how fast you will reach that number. If you think that will happen next week I would maybe not do it. If it is something farther down the line like multiple months or a year then it should be fine as multi-tenancy is anyway on the roadmap for larger enterprise deployments.

Ok. I’ve come up with a better solution in the meantime.

I have setup webhooks on a real server for all my repos and then have that server call one custom webhook in n8n

Ah yes, that sounds also good!