I’m looking for a way to dynamically determine which stored credential a node uses at runtime, based on data in the workflow (for example, an incoming field like “cluster” or “environment”), rather than having the credential fixed per node.
To be clear, I don’t mean passing a raw API key/secret as an expression value inside the workflow. I specifically want to reference and switch between different stored n8n credentials depending on the execution, so the actual secret stays managed in the credential store rather than being exposed in the workflow itself.
My use case: we have a workflow that triages alerts coming from multiple Elastic clusters, each with its own stored credential. We’d like a single node to select the correct credential per execution depending on which cluster the data came from, instead of duplicating nodes or workflows per cluster.
Is this currently possible in n8n in any way (through an expression on the credential field, some kind of credential-picker logic, or another mechanism), or is this not supported today?
There is no dynamic option to select a credential. However, you can make a sub workflow, that will trigger a node with a predefined credential based on criterias you choose.
E.g. I have multiple HTTP nodes with their own credentials that handle operations automatically based on the input
Hi @ntoll01
The selectable part can be the sub-workflow rather than the credential. One workflow per cluster, each holding a single node with that cluster’s credential, called from the triage workflow with Execute Sub-workflow set to Source: Database and an expression in the Workflow ID field that maps the incoming cluster name to its ID. Adding a cluster is then a new workflow plus one row in that map, with nothing on the triage side growing.
Each of those sub-workflows needs its “This workflow can be called by” setting to allow the caller, or the call fails at runtime.
The native version of what you asked for is an open feature request, worth an upvote:
Not supported natively. You cannot put an expression on the credential picker, and the feature request for it has been open since 2021. Native nodes lock the credential at design time.
What you can do instead:
If you’re on Enterprise, look at Dynamic Credentials and External Secrets. That’s the proper version of what you’re describing, credentials resolved at runtime rather than fixed on the node.
For Elastic specifically there’s a simpler option. Use an HTTP Request node instead of the Elastic node, store each cluster’s endpoint and key in a lookup, and set the auth header by expression. You lose the node’s convenience but you get one node handling all clusters. The trade-off is the key sits in execution data rather than the credential store, which may not be acceptable given what you said about keeping secrets managed.
Are you on Enterprise? That decides which of these is actually open to you.
@barn4k I’ve thought about multiple HTTP nodes, but in our situation we have 5 HTTP nodes for creating the case, adding alerts, setting the status, etc. For 4 clusters that’s already 20 HTTP nodes.
@Lopez we’re on a business license so no possibility of using External Secrets sadly. I’ve looked into the workaround and it looks promising, will dig into that.
@Anshul_Namdev this will probably be our first workaround, using a router workflow with sub-workflows per customer.
@n8n is there currently a technical challenge to putting an expression on the credential picker? These workarounds all seem way more complex than a problem that could just be handled with an expression, and the scalability of our API calls would be a lot better with it.
