How to create node properties dynamically?

I am trying to create a node whose properties need to be dynamically displayed based on the results of an API call.

Currently the properties of a node are defined in a node statically like this

       properties: [
		{
			displayName: 'Operation',
			name: 'operation',
			type: 'options',
			options: [
				{
					name: 'Find',
					value: 'find',
					description: 'Find documents.',
				},
				{
					name: 'Insert',
					value: 'insert',
					description: 'Insert documents.',
				},
				{
					name: 'Update',
					value: 'update',
					description: 'Updates documents.',
				},
			],
			default: 'find',
			description: 'The operation to perform.',
		},
		{
			displayName: 'Database',
			name: 'database',
			type: 'string',
			required: true,
			default: '',
			description: 'MongoDB Database to connect to'
		},
		{
			displayName: 'Collection',
			name: 'collection',
			type: 'string',
			required: true,
			default: '',
			description: 'MongoDB Collection'
		},
]

Each of these properties is defined in advance and are static. Is there any way to load the properties dynamically? All of them? or some new ones after a previous property has been selected?

I know how to use the loadOptionsMethod param within a property to get a list of possible values like this

typeOptions: {
				loadOptionsMethod: 'getDatasources',
			},

But in my use-case, I want to create the properties themselves.

Is there any existing way to do this? If not, what could be a simple approach to make this work. I am open to taking direction and then making changes in the core.

No, that is currently sadly not possible.

Honestly not sure right now what a simple approach would be. Never thought about it. But out of the top of my head I see the chance that it could cause some problems esp. when the node gets executed. At that point n8n has to know which parameters the node has. If that is not “hardcoded” like now, it would have to either:

  • load them also then again dynamically (would be slow, could cause problems if it would return different parameters than before to the UI, …)
  • would have to save them with the node in the workflow after they have been loaded (which would blow up the workflow a lot and would probably also cause some other issues but still better than the other alternative)

In general would it probably be a nightmare to debug and to create such nodes and workflows and the chance that they fail would be much higher than with “regular fixed nodes”. So not sure it it would be really worth the trouble right now.

For the sake of argument:

Option 1 seems to be relatively simpler to implement but the issue is of different parameters being returned at node execute time. Lets say if that possibility of different parameter responses went away by other means, what would be your take then?

PS: I am not asking for a feature request that you would have to implement.

Not sure if 1 would be much simpler than 2. Both are probably not incredible huge amounts of work and that complicated. But are for sure a bigger fan right now making sure that the parameters and defaults the user did see and set are the one being processed later.
Esp. thinking about security. If a parameter gets used to send for example data to. The user leaves it at the default value (lets say official Jira-API) but the function would then suddenly return a different default value (external Fake API) all the data would get send there.

Do not think the “different parameter responses” can be avoided. Is after all something totally out of our control. How it would work is that it probably would call some kind of function which returns the parameters to add. This function could then do an HTTP Request, dynamically create them depending on the time of the day, … or whatever.

I am also developing a node that requires dynamic properties, which I was able to do when making a Zapier integration for our API. I believe this should work, but I have not tried it yet. @Talha_Khan is this what you were referring too?

By Dynamic properties, I meant that the input fields of the node to be displayed can also be controlled via an API call. Not just the values. Based on the answers from Jan, we decided to take a little bit of a different direction and used fixedCollection type intead of options
fixedCollection can be hooked up to an API and display options dynamically. They are a bit different though. You go and click on a button called something like Add Option and then the keys/values can be shown.