I was following this thread for the same general reason as the rest of you, and found a workaround that may help some people here.
It does not dynamically select a different saved credential instance by ID. That still appears to be the missing feature.
However, for credential types where the important value is just an API key/token value, you can do it the other way around:
Use one fixed credential instance, but make the credential field itself dynamic using an expression.
So instead of:
Dynamically choose Credential A, B, or C
you do:
Use one credential, but dynamically resolve the API key/token inside that credential at runtime
For example, imagine you have an Edit Fields / Set node earlier in the workflow called:
Runtime Config
and that node outputs an apiKey field.
Option 1: Use a runtime key, otherwise fall back to a default key
In the credential’s API key field, you could use:
{{ $('Runtime Config').first().json.apiKey || 'your-default-api-key-here' }}
That gives you:
apiKey has a value → use that value
apiKey is missing or empty → use the default key
This is useful where you want a normal/default account to be used unless the workflow provides something else.
Option 2: Use a runtime key only, otherwise let the workflow fail
If you do not want any fallback at all, you can simply use:
{{ $('Runtime Config').first().json.apiKey }}
That gives you:
apiKey has a value → use that value
apiKey is missing or empty → the credential resolves to empty/undefined and the node should fail
That may actually be preferable in some cases. If the workflow is supposed to provide a runtime credential value, failing loudly is often better than silently using the wrong/default account.
One thing worth noting: when you are editing the credential itself, the expression may show undefined or fail to preview. That makes sense, because the credential does not inherently know which workflow, execution, or node it will be attached to.
The important part is that once the credential is actually used by a node inside a workflow, the expression is evaluated in that workflow execution context. So references such as:
$('Runtime Config').first().json.apiKey
can resolve correctly at runtime, even if they appear as undefined while viewing or testing the credential in isolation.
This works because n8n supports expressions inside credential fields. So the node still uses a normal, fixed credential reference, but the value inside that credential is resolved dynamically at execution time.
This is effectively an inverse workaround for this feature request:
Not dynamic credential selection:
"Choose which credential ID to use"
But dynamic credential value resolution:
"Use this credential, but resolve the API key/token from the workflow execution"
Obviously there are caveats:
-
This is mostly useful for simple API-key/token-style credentials.
-
I would not expect this to solve OAuth-style credential switching cleanly.
-
If you hardcode a fallback key inside the expression, that fallback key is readable to anyone who can view/edit that credential.
-
If the runtime key comes from workflow data, be careful with execution-data saving/redaction so you don’t store secrets in execution history.
But for cases where you just need a credential-backed node to use a runtime-provided API key, this seems to work very well and avoids creating temporary credentials, updating workflow JSON, executing a second workflow, then deleting the credential afterwards.
Or, it avoids creating many duplicates of the same workflow to handle different client keys.
This is a MAJOR win as I use nodes that REQUIRE credential instance selection!
It is not the same as dynamically selecting credentials by ID, but for many API-key-based integrations it achieves the practical outcome in a much cleaner way.
