n8n credentials explained

Credentials in n8n are stored authentication details (API keys, OAuth tokens, database passwords) that nodes use to connect to services. They live separately from workflows, are encrypted in the database, and are referenced by ID. That separation is why workflows can be exported and shared safely, and also why every migration involves a credential checklist. This page explains how n8n credentials work end to end.

For moving secrets from Pipedream specifically, see Pipedream secrets to n8n credentials.

Create a credential

Three ways (docs):

1. Overview > Create credential, then pick the service. It lands in your personal space.
2. Inside a project, so the credential belongs to that project (instances with projects).
3. From a node's Credential dropdown > Create new credential, while building the workflow.

n8n tests the credential when you save it. A failed test usually means a wrong key, a missing scope, or (for self-hosted) an OAuth redirect URL that doesn't match your public n8n URL.

Naming

n8n names new credentials "node name account" by default. With ten Slack workspaces or separate test and production keys, that gets confusing fast. A convention such as Slack – Acme workspace – bot or Stripe – live – read-only saves time when you reconnect imported workflows.

Allowed HTTP Request Domains

Many credentials have an Allowed HTTP Request Domains field: All, Specific Domains (comma-separated), or None. It controls where the credential may be sent when it's used in an HTTP Request node, and has no effect in the service's own node. Set it to the API's domain for anything sensitive, so a typo or a malicious edit can't send your token to another host.

Expressions in credential fields

Credential fields accept expressions, so a credential can pick a value from workflow data at runtime, for example a per-tenant API key read from an earlier node. Use it sparingly: the value then sits in execution data like any other field.

Fixed vs end-user credentials

For OAuth credentials on n8n Cloud Enterprise and self-hosted Enterprise you can choose a Credential type: Fixed credential (default; same credential whoever runs the workflow) or End-user credential (each user's own connection, private to them).

Credential types you'll use most

Need	Credential
Service n8n supports (Slack, Google, HubSpot…)	The service's own credential (OAuth2 or API key)
Any REST API with a key in a header	Header Auth
Key in the query string	Query Auth
Username/password	Basic Auth
OAuth2 provider n8n has no node for	OAuth2 API (generic)
Webhook protection	Basic, Header or JWT auth on the Webhook node

For an endpoint the app node doesn't cover, use an HTTP Request node with Predefined Credential Type and reuse the same credential.

Why Code nodes can't read credentials

By design, the Code node has no access to credentials: this.getCredentials() and $getCredentials() fail (Code node common issues). The intended pattern:

• Make authenticated calls in HTTP Request or app nodes.
• Use the Code node to prepare data before and process responses after.
• To choose a credential dynamically, route with a Switch node to nodes with different credentials, or use expressions in credential fields.

This is the biggest change for people coming from platforms where code had direct access to tokens.

Sharing

Plan	Credential sharing
n8n Cloud	All plans
Self-hosted Business, Enterprise	Yes
Self-hosted Community	No: only the owner and creator can access a credential

Share from Credentials > (credential) > Sharing with users or projects (docs). People you share with can use the credential in their workflows but can't view or edit its details. Instance owners and admins can view and share all credentials.

Encryption key

Credentials are encrypted with N8N_ENCRYPTION_KEY. If you don't set it, self-hosted n8n generates a random key on first launch and stores it in the config file in ~/.n8n (deployment variables, backup and restore).

Practical rules for self-hosting:

• Set the key explicitly and keep it in your secrets manager. A recreated container with a new random key can't decrypt existing credentials.
• Back up the key with the database. One without the other is useless.
• In queue mode, every worker needs the same key as the main instance.

Export and import

Workflow exports carry credential names and IDs only, never the secrets (export and import). After importing a workflow into another instance you select or create the credential on each node.

Moving credentials between self-hosted instances is a server CLI job (CLI docs):

# encrypted with the source instance's key
n8n export:credentials --all --output=backups/creds.json

# plain text, for a target instance with a different key
n8n export:credentials --all --decrypted --output=backups/decrypted.json

n8n import:credentials --input=backups/decrypted.json

The decrypted file contains every secret in clear text. Create it on the server, move it over an encrypted channel, import, and delete it. IDs are preserved, so imported credentials with matching IDs overwrite existing ones.

Credentials, Variables and environment variables

Store	Use for	Readable in Code node
Credentials	Secrets used by nodes to authenticate	No
Variables ($vars)	Non-secret config shared across workflows (Cloud Pro/Enterprise, self-hosted Business/Enterprise)	Yes
Environment variables ($env)	Instance config on self-hosted	Only if not blocked
External secrets ($secrets)	Vault-backed secrets, Enterprise	In credential fields only

Details in n8n environment variables.

A credential checklist for migrations

1. List every service the imported workflows use.
2. For each, decide: new OAuth connection, new API key, or existing key.
3. Create the credentials with clear names, set Allowed HTTP Request Domains.
4. Open each imported workflow, select the credential on every node, save.
5. Run each workflow once with test data before publishing.

From Pipedream connected accounts

Pipedream's export redacts every secret prop to <redacted> and keeps only an authProvisionId for connected accounts; environment variables aren't exported at all (Pipedream export). Pipedream also deletes connected accounts and OAuth tokens with the rest of Workflows data by April 30, 2027. So every credential has to be recreated in n8n from the provider.

Our converter report lists, per workflow, which apps need a credential, so steps 1 and 4 above are a checklist rather than a hunt. Code steps that read this.<app>.$auth need the call moved to an HTTP Request node; the code step checker shows which. The report and 1 workflow are free. Full export: $3 per workflow, $19 minimum — coming soon.

Not affiliated with Pipedream or n8n.