J'ai un problème général avec n8n auto-hébergé et les workflows importés depuis JSON

Feedback General
1

Bonjour à tous,
J’ai un problème général avec n8n en mode self-hosted et les workflows importés à partir de JSON.
Ce ne n’est pas seulement un problème avec Slack. Cela se produit avec plusieurs intégrations :

  • Slack
  • Airtable
  • Notion
  • Shopify
  • OpenAI
  • Gemini
  • OpenRouter
  • Google Drive
  • Gmail
  • autres identifiants similaires

Contexte :

  • Les identifiants sont créés dans n8n.
  • Les identifiants testent correctement la connexion.
  • Ils sont créés dans le même environnement n8n.
  • Les tokens/clés API fonctionnent.
  • Mais lorsque j’ouvre un nœud dans un workflow importé à partir de JSON, la liste déroulante des identifiants apparaît vide ou affiche « Aucun identifiant pour le moment ».
  • Recharger le navigateur ne le résout pas.
  • Vider le cache ne le résout pas non plus.
  • Le problème se produit avec les nœuds importés, pas seulement avec un nœud spécifique.

Ce qui est étrange :
Si j’appuie sur « Configurer l’identifiant » dans le nœud lui-même et que je crée un nouvel identifiant à partir de là, le nœud commence alors à reconnaître les identifiants et fonctionne.

La solution temporaire que nous utilisons est :

  1. Créer un nouvel identifiant/faux depuis le nœud lui-même.
  2. Ensuite, n8n permet déjà de choisir un identifiant.
  3. Sélectionner ou recréer l’identifiant correct.
  4. Ensuite, supprimer l’identifiant temporaire.

Mais ce n’est pas pratique, car il faudrait le faire sur de nombreux nœuds et nombreuses intégrations.

Question principale :
Comment corriger correctement ce problème ?

Questions spécifiques :

  1. Est-ce un problème de propriété/contexte utilisateur/projet dans n8n ?
  2. Les identifiants créés à partir de l’écran Identifiants ne sont-ils pas disponibles pour les workflows importés pour une raison quelconque ?
  3. Existe-t-il un moyen de réassigner ou de relier les identifiants existants aux workflows importés sans les recréer nœud par nœud ?
  4. Existe-t-il une commande CLI ou une méthode recommandée pour importer des workflows et maintenir ou réassigner des identifiants ?
  5. Est-il nécessaire que le workflow et l’identifiant appartiennent exactement au même utilisateur/projet ?
  6. Peut-on corriger cela depuis l’interface n8n, la base de données, la CLI ou l’API ?
  7. n8n MCP / Claude Code peut-il assigner des identifiants existants aux nœuds importés, ou pour des raisons de sécurité, cela doit-il se faire manuellement ?

Environnement :

  • n8n self-hosted
  • Workflows importés à partir de JSON
  • Identifiants créés dans n8n
  • Les identifiants testent correctement
  • Le problème affecte plusieurs applications, pas seulement Slack
  • Créer l’identifiant depuis le nœud lui-même fonctionne

J’ai besoin de savoir quelle est la bonne façon de le résoudre de manière globale, pas nœud par nœud.
Merci.

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
3

Welcome @miki007 to our community! I’m Jay and I am a n8n verified creator.

This is expected behavior - when you import a workflow JSON, the credential IDs inside the JSON won’t match the IDs on your instance, so nodes show empty dropdowns. The cleanest fix: after importing, use the “Credential” dropdown in each affected node - since your credentials are already created and tested, they should appear in the list, just not pre-selected. Select the right credential and save. If you’re importing many workflows, n8n CLI has an n8n import:workflow command that can help with bulk operations, though manual re-mapping is still needed for credentials unless you’re migrating between identical instances using n8n export:credentials + n8n import:credentials.

4

Thanks for the answer. I understand that imported workflow JSON files keep credential IDs/names from the original instance and that these IDs won’t match my instance automatically.

However, my issue is a bit different: the problem is not only that credentials are not pre-selected. In many imported nodes, the credential dropdown is completely empty or shows “No credentials yet”, even though the credentials already exist in the same n8n instance and test successfully.

If I create a new credential from inside that same node using “Set up credential”, then the node starts recognizing credentials. That makes me think it may be related to one of these:

  1. the imported workflow and the existing credentials belong to different users/projects/spaces;

  2. the imported node expects a different credential type than the credential I created from the Credentials screen;

  3. the workflow was imported into the wrong user/project context.

So my follow-up question is:

What is the recommended way to globally fix this?

Should I import workflows with n8n import:workflow --projectId or --userId so they land in the same context as the credentials?

Is there a supported way to reassign existing credentials to imported workflows in bulk, or is manual remapping/recreating nodes required?

I’m trying to avoid creating temporary credentials node by node across many workflows.

5

Your diagnosis is right - option 1 is almost certainly the cause. The --projectId and --userId flags in n8n import:workflow control which project/user owns the workflow, but they don’t remap credential IDs inside the workflow JSON. There’s no built-in bulk credential reassignment. The cleanest approach for bulk imports is to export your credentials from the source instance with n8n export:credentials --all, import them to the new instance with n8n import:credentials, and then import the workflows - since the credential IDs will match, nodes won’t show empty dropdowns. If you’re starting fresh without the source credentials, the fastest workaround is still the “Set up credential” trick you already found, since it forces the node to register with a valid ID on your instance.