Clarify behaviour of Credential Overwrite

Describe the problem/error/question

What is the behaviour of CREDENTIAL_OVERWRITE_DATA ?

My Assumptions:

Credential Overwrite defines default values, which are utilized when you create new credentials.

What i need is

a way to define credentials which have the same id and name in all my self hosted installations, so i can utilize them in a workflow saved as file, which i execute via a node.
i tried to export and import the creds, and expected credential overwrite to overwrite the username and password in the imported credentials.

Use case:

embedded Workflow engine utilize helper workflow to

  • update the status of the execution in the parent app
  • issue actions with custom nodes against the parent app

Thanks for any answer which clarifies the behaviour, and or suggest a way of doing it.

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Hey @Martin_Forster,

CREDENTIAL_OVERWRITE_DATA is used to set predefined credential options that a user can’t change, Normally this is useful for OAuth if you just want users to a “click to connect” button and not have to worry about entering the details for the client application.

You can find the documentation on this option in the embed documentation here: Configuration | n8n Docs

I use this feature on my personal n8n instance and my development environment so that if I am testing an issue I don’t need to mess around with getting the secrets for Microsoft / Google services and I can just connect and get on with testing.

What this doesn’t do though is give you a way to define credentials that have the same ID as you still need to create the credential to use it, I have not tried it on API keys though to see what happens with those.

If you wanted to share credentials with the same ID that is where the enterprise feature for git comes in as it does exactly what you are after. I guess a really ugly solution could be to directly change the ID of the credential in the database after you import it although I have not tested just exporting and importing since we changed the IDs before v1 so it could be that we now import with the same ID as the export if the credential doesn’t exist already.

1 Like

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