How to Dynamically Load Credentials in a Code Node? ($getCredentials is not defined)

Questions
1

Hi community,
I’m building a multitenant workflow and need to dynamically load a credential inside a Code node based on an incoming clientId.
My plan is to create a Custom Auth credential for each client with a consistent naming convention (e.g., api_client_abc, api_client_xyz). Then, in the Code node, I try to fetch the correct one based on the clientId from the input.
However, I’m finding that the functions to access credentials programmatically are not available.
I have tried two approaches, and both fail:
Using this.getCredentials()
JavaScript
const credentialName = api_${clientId};
const credentials = await this.getCredentials(credentialName);
This fails with the error: this.getCredentials is not a function.
Using $getCredentials()
JavaScript
const credentialName = api_${clientId};
const credentials = await $getCredentials(credentialName);
This fails with the error: $getCredentials is not defined.
I am running a self-hosted n8n instance, version 1.106.3.
My questions are:
Is there a different, correct syntax for programmatically accessing credentials by name within a standard Code node for this version?
Or, if this functionality is not available in the standard Code node’s context, what is the recommended “n8n-native” way to achieve dynamic credential selection based on input data?
Thanks for any guidance you can provide.

2

Hey @Lorena_Lopez hope all is well.

I don’t believe you can access and use credentials dynamically like this.
What kind of credentials are you working with? Is it API keys? Is it header based?

3

Thanks for the quick reply! That confirms what I was starting to suspect.

To answer your question: Yes, it is a header-based API key.

The custom API I’m calling requires a single, simple header for authentication: API-KEY: <secret_token>.

My goal is to support multiple clients, where each client has a different secret API key. The incoming request to my webhook includes a clientId, so I know which client’s key to use for each execution.

Given that I can’t dynamically load credentials by name in a Code node, what is the recommended n8n pattern for this kind of multitenant scenario?

Should I use a Switch node to route to different HTTP Request nodes (one per client), or is there a more elegant way to set a header value dynamically from a credential store?

Thanks again for your help!

4

In this case you could create a mapping of clientId to api key, and during the execution, extract the key based on the clientId and provide this to the following HTTP Request node. In the HTTP Request node you could set the header with key API-KEY and expression based value {{ $json.api_key }}.

The mapping could be as simple as a Code node or an additional call to a third party Vault service.

5

Hi Jabbson,

Thanks again for your excellent suggestion about using a mapping structure. It’s a much more elegant approach.

We tried to implement this securely by storing the map of clientId to credential details (URL, API Key) in a single, master Custom Auth credential, instead of having plain-text keys in the code. The plan was to have a Code node:

  1. Read the incoming clientId.

  2. Load the master Custom Auth credential.

  3. Look up the correct URL and API Key from the JSON map inside the credential.

  4. Pass these values to the final HTTP Request node.

Unfortunately, we’ve hit a definitive roadblock: in my self-hosted environment (v1.106.3), the Code node seems to have no access to the credential store at all. Any attempt to access the $credentials object from the code results in an error: "$credentials is not defined".

This seems to leave us with only one viable, albeit more manual, alternative: using a Switch node. The flow would be to route based on clientId to a different HTTP Request node for each client. Each of these HTTP Request nodes would then have its specific client credential selected manually in the UI.

Before I go down that path, I wanted to ask for your expert opinion: Is this Switch node architecture the correct and most robust pattern for a multitenant setup when programmatic credential access in the Code node isn’t possible?

Thanks again for your invaluable help.

1 Like
6

Hey @Lorena_Lopez,
yes, I don’t believe the code node can access credentials.

Any other way of passing sensitive data wouldn’t be as secure.
You could use switch, you could use the code node with mapping (a structure with keys of clientIds and values of the keys), or you could try to utilize external data vaults.

1 Like
7

Hi Jabbson and community,

I’m following up to confirm that our issue is now solved. A huge thank you to everyone who contributed, especially Jabbson for validating the final approach.

For anyone else facing a similar multitenant challenge where you need to dynamically select credentials for an HTTP request and programmatic access in the Code node isn’t an option, here is the final, robust architecture that worked for us.

The Solution: “Switch” Node Architecture

The core challenge was that the Code node in our self-hosted environment could not access the $credentials object, making dynamic loading impossible. The solution was to use a Switch node to route traffic to a dedicated HTTP Request node for each client.

1. Credential Setup (One per Client): We created one Header Auth credential for each client. This keeps all secret API keys securely in the n8n vault.

  • Credential Name: API Key - Client ABC

  • Header Name: API-KEY

  • Header Value: SECRET_KEY_FOR_CLIENT_ABC

2. Centralized Configuration (Code Node): An upstream Code node handles all the non-secret logic. It prepares the query parameters and contains a simple JavaScript map of clientId to that client’s specific API URL.

JavaScript

// Example map inside an upstream Code node
const clientConfigMap = {
  'client_abc': { url: 'https://api.client-abc.com/v1/' },
  'client_xyz': { url: 'https://api.client-xyz.com/v1/' }
};
// This node's output includes the specific URL for the current client,
// the final request body, and the clientId.

3. Routing (Switch Node): A Switch node routes the workflow based on the clientId received from the upstream Code node.

4. Dedicated Execution (HTTP Request Node per Client): We placed a separate HTTP Request node on each branch of the Switch. The configuration for each is simple and reliable:

  • Authentication: Set to Header Auth in the dropdown.

  • Credential: Manually select the specific Header Auth credential for that client (e.g., API Key - Client ABC) from the credential dropdown. This is the key step.

  • URL: Use an expression to pull the dynamic URL from the upstream Code node (e.g., {{ $json.apiUrl }}endpoint).

  • Body: Use an expression to pull the prepared request body.

This Switch pattern completely bypasses the Code node’s limitations for accessing credentials and provides a secure, reliable, and visually clear way to manage a multitenant workflow.

Thanks again for guiding us to this solution!

1 Like
8

Thank you for getting back and sharing your final thoughts with the community.

If my answer was useful, and steered you in the right direction, kindly mark it as a solution, thank you.

Cheers!

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.