I am looking for an n8n API to cereate a new credentials, not for HTTP request nodes

Describe the problem/error/question

I would like that any of my customer will use its own credentails (aka google sheet, postgres, airtable etc…)

and not a credentials inside the body, such as nano banana or other HTTP request nodes

What is the error message (if any)?

no Error message

can you share your workflow

There is no need for the workflow my friend it is a very general question,.

Anyone? can ypu help here?

Take a look at the API references, there is a section about Credentials and a post request.

I am asking for a way to do a dynamic credentials - Is it possible?

Attempts to programmatically select or switch credentials (for example, based on user input or workflow data) are not natively supported.

The Code node cannot access or switch credentials dynamically, and there is no built-in function to fetch or assign credentials by name at runtime within a node.

Hey.

Not really code node.

Im.talking about credentials ss variables

Creating Credentials via API

You can use the n8n node or make direct API calls to create credentials for your customers.

Using the REST API

You can also call the API endpoint directly:

POST https://<n8n-domain>/rest/credentials

With a request body like:

{
  "name": "Customer Google Sheets",
  "type": "googleSheetsOAuth2Api",
  "data": {
    "clientId": "customer_client_id",
    "clientSecret": "customer_client_secret"
  }
}

Finding Credential Type Names

To find the correct credential type name for services like Google Sheets, Postgres, or Airtable:

  1. Use the Get Schema operation to retrieve the credential structure

  2. Check the n8n GitHub repository for credential type names

  3. The credential type name is defined in each credential file (e.g., googleSheetsOAuth2Api, postgresDb, airtableApi)

Important Considerations

For a multi-customer setup where each customer uses their own credentials:

  • You’ll need an Embed license if customers are using your n8n instance

  • Consider the workflow per user approach for managing customer-specific credentials

  • Each customer’s credentials should be created separately and associated with their specific workflows

This approach allows you to programmatically create credentials for services like Google Sheets, Postgres, and Airtable without using HTTP Request nodes.

If you’re asking whether **credentials can be used AS variables** (meaning accessing credential values like you would access variables), the answer is:

## Credentials vs Variables - Key Differences

**Custom Variables** (`$vars`):

- [Available on Enterprise and Pro Cloud plans]( Custom variables | n8n Docs )

- Accessed using `$vars.`

- Read-only, shared across all workflows

- Used for non-sensitive configuration data

**Credentials**:

- Used for authentication to external services

- **Cannot be accessed like variables** in Code nodes or expressions for security reasons

- Values are encrypted and not directly accessible as `$vars` would be

## What You CAN Do

1. **[Use expressions within credential fields]( Create and edit | n8n Docs )** - You can reference workflow data when setting up credentials

2. **[Use external secrets]( External secrets | n8n Docs )** - Reference secrets from external vaults using `{{ $secrets.. }}`

## What You CANNOT Do

- Access credential values programmatically like `$vars` or `$credentials` in Code nodes

- Use credentials as general-purpose variables

- [Dynamically change credentials within a workflow]( How can we change credentials dynamically in a single node ) based on runtime conditions

The separation is intentional for security - credentials are encrypted and handled differently than regular variables. If you need to store non-sensitive configuration data that can be accessed like variables, use Custom Variables instead.

1 Like