n8n-io/n8n · error · UserError

Provider connections cannot be global, managed, or dynamical

Error message

Provider connections cannot be global, managed, or dynamically resolved

What it means

Thrown by `import:credentials` when a credential being imported has `usageScope === 'instance'` AND any of the resolver/global/managed flags is set (isGlobal, isResolvable, isManaged, resolvableAllowFallback, resolverId). Instance-scope provider connections are simple credentials that do not participate in the dynamic resolution / managed / global credential system — those features are for project-scope credentials.

Source

Thrown at packages/cli/src/commands/import/credentials.ts:200

					credential.type !== existing.type
				) {
					throw new UserError(
						'Provider connection type cannot be changed. Create a new connection instead.',
					);
				}
			}
		}
		credential.usageScope ??= 'project';

		if (credential.usageScope === 'instance') {
			if (
				credential.isGlobal ||
				credential.isResolvable ||
				credential.isManaged ||
				credential.resolvableAllowFallback ||
				credential.resolverId
			) {
				throw new UserError(
					'Provider connections cannot be global, managed, or dynamically resolved',
				);
			}
			Object.assign(credential, {
				isGlobal: false,
				isResolvable: false,
				isManaged: false,
				resolvableAllowFallback: false,
				resolverId: null,
			});
			await this.validateInstanceCredentialData(transactionManager, credential, existing, ctx);
		}

		const result = await transactionManager.upsert(CredentialsEntity, credential, ['id']);
		const credentialsId = credential.id ?? (result.identifiers[0].id as string);

		if (credential.usageScope === 'instance') {
			// Instance credentials are instance-owned and must not retain project sharing rows.

View on GitHub (pinned to 5ac6606e81)

Solutions

1. If the credential must be instance-scoped, remove all of: isGlobal, isResolvable, isManaged, resolvableAllowFallback, resolverId from the JSON.
2. If the credential must be global/managed/resolvable, set `usageScope: "project"` (or omit it — it defaults to 'project' at credentials.ts:190).

Example fix

// before
{ "usageScope": "instance", "isGlobal": true, "type": "..." }
// after
{ "usageScope": "instance", "type": "..." }

function validateInstanceCredentialFlags(c: Partial<CredentialsEntity>) {
  if (c.usageScope === 'instance') {
    const incompatible = ['isGlobal', 'isResolvable', 'isManaged', 'resolvableAllowFallback', 'resolverId'] as const;
    for (const key of incompatible) {
      if (c[key]) throw new Error(`Instance credential cannot set ${key}`);
    }
  }
}
validateInstanceCredentialFlags(credential);

When it happens

Trigger: Import JSON sets `usageScope: "instance"` alongside `isGlobal: true`, `resolverId: "..."`, `isManaged: true`, etc. The check at credentials.ts:192-203 fires before the credential is upserted.

Common situations: Hand-crafted JSON mixing incompatible credential features; exporting a project-scope managed credential and forcing instance scope on re-import; downstream tooling that sets all flags defensively.

Related errors

• Provider connection type cannot be changed. Create a new con
• You cannot use `--userId` and `--projectId` together. Use on
• You cannot use `--include` and `--exclude` together. Use one
• Provider connection data cannot be empty
• Provider connection data must be a JSON object

AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12). Data as JSON: /api/errors/95de42660f216554. Report an issue: GitHub.