{“output”:“Je remarque un comportement incohérent dans la dénomination des identifiants dans n8n et je veux confirmer si c’est attendu.\n\n### Ce que j’observe\n\n* Pour mon type d’identifiant personnalisé (myApi), les nouveaux identifiants sont automatiquement nommés globalement sur l’instance :\n\n * L’utilisateur A crée des identifiants personnels : MyApi Account, MyApi Account 2\n\n * L’utilisateur B (qui ne peut pas voir les identifiants personnels de l’utilisateur A) en crée un et obtient : MyApi Account 3\n\n* Mais par exemple, pour les identifiants OpenAI, le compteur semble être personnel/étendu au projet (il ne continue pas à partir des identifiants d’autres utilisateurs de la même manière).\n\n### Pourquoi c’est confus\n\nLa visibilité des identifiants est personnelle/basée sur les projets, mais le suffixe du nom généré pour mon type personnalisé semble utiliser un compteur global. Cela rend la dénomination apparemment "transparente" entre les utilisateurs même si les identifiants ne sont pas partagés.\n\n### Question\n\n* Cette différence entre les types d’identifiants intégrés (par ex. OpenAI) et personnalisés est-elle attendue ?\n\n* Existe-t-il plusieurs flux de création d’identifiants/génération de noms dans n8n qui expliquent cela ?\n\n* Y a-t-il un moyen pour un type d’identifiant personnalisé d’utiliser une génération de noms par utilisateur/par projet au lieu d’un suffixage global ?\n\n\"n8n-workflow\": \"^1.120.13\"”}
Bienvenue dans la communauté n8n @Jankaz
avez-vous vérifié si la credential OpenAI est créée par le même flux que votre credential personnalisé (projet personnel vs projet partagé vs projet global du propriétaire) ?
J’ai l’impression que votre problème se situe dans le chemin interne de création/nommage qui est utilisé. Pouvez-vous partager une repro simple en comparant credential personnalisé vs credential OpenAI, en incluant le projet, le rôle de l’utilisateur, les noms générés et le comportement de la numérotation entre utilisateurs ?
J’ai vérifié les requêtes dans le réseau et les deux utilisent https://n8n.stg.olx.org/rest/credentials avec la même structure de payload. Les deux avec le même projectId. La seule différence est que le payload pour openai a un champ supplémentaire uiContext: "credentials_list" mais je suppose que ce n’est pas le cas
MyApi.credentials.ts
export class MyApi implements ICredentialType {
name = "myApi";
displayName = "My API";
properties: INodeProperties[] = [
{
displayName: "URL de base de la plateforme",
name: "baseUrl",
type: "string",
default: "http://myapi.com",
placeholder: "http://myapi.com",
required: true,
hint: "Cliquez sur `Enregistrer` pour vous authentifier.",
description: "",
},
{
displayName: "Secret",
name: "adminToken",
type: "hidden",
typeOptions: {
password: true,
},
default: "",
description:
"Rempli via les remplacements de credentials n8n.",
},
];
test: ICredentialTestRequest = {
request: {
method: "GET",
baseURL: "={{$credentials.baseUrl}}",
url: "/health",
},
};
}
import type {
ICredentialDataDecryptedObject,
ICredentialTestRequest,
ICredentialType,
IHttpRequestOptions,
INodeProperties,
} from 'n8n-workflow';
export class OpenAiApi implements ICredentialType {
name = 'openAiApi';
displayName = 'OpenAI';
documentationUrl = 'openai';
properties: INodeProperties[] = [
{
displayName: 'Clé API',
name: 'apiKey',
type: 'string',
typeOptions: { password: true },
required: true,
default: '',
},
{
displayName: 'ID d\'organisation (optionnel)',
name: 'organizationId',
type: 'string',
default: '',
hint: 'Obligatoire uniquement si vous appartenez à plusieurs organisations',
description:
"Pour les utilisateurs qui appartiennent à plusieurs organisations, vous pouvez définir l'organisation utilisée pour une demande d'API. L'utilisation de ces demandes d'API sera facturée à la limite de quota d'abonnement de l'organisation spécifiée.",
},
{
displayName: 'URL de base',
name: 'url',
type: 'string',
default: 'https://api.openai.com/v1',
description: 'Remplacer l\'URL de base par défaut de l\'API',
},
{
displayName: 'Ajouter un en-tête personnalisé',
name: 'header',
type: 'boolean',
default: false,
},
{
displayName: 'Nom de l\'en-tête',
name: 'headerName',
type: 'string',
displayOptions: {
show: {
header: [true],
},
},
default: '',
},
{
displayName: 'Valeur de l\'en-tête',
name: 'headerValue',
type: 'string',
typeOptions: {
password: true,
},
displayOptions: {
show: {
header: [true],
},
},
default: '',
},
];
test: ICredentialTestRequest = {
request: {
baseURL: '={{$credentials?.url}}',
url: '/models',
},
};
async authenticate(
credentials: ICredentialDataDecryptedObject,
requestOptions: IHttpRequestOptions,
): Promise<IHttpRequestOptions> {
requestOptions.headers ??= {};
requestOptions.headers['Authorization'] = `Bearer ${credentials.apiKey}`;
requestOptions.headers['OpenAI-Organization'] = credentials.organizationId;
if (
credentials.header &&
typeof credentials.headerName === 'string' &&
credentials.headerName &&
typeof credentials.headerValue === 'string'
) {
requestOptions.headers[credentials.headerName] = credentials.headerValue;
}
return requestOptions;
}
}
@Jankaz
D’après le code du backend, il semble que le POST /rest/credentials persiste le nom reçu dans le payload, donc j’investiguerais la génération du nom dans le frontend avant que la requête ne soit envoyée. Si OpenAI et la credential customisée arrivent au même endpoint avec le même projectId, mais avec des noms déjà différents, la différence est probablement dans le flux UI qui calcule le nom de credential par défaut, pas dans le save() du backend.
Merci - d’accord pour dire que POST `/rest/credential` sauvegarde simplement le nom fourni.
Dans les traces réseau, les deux identifiants OpenAI et personnalisés appellent également `GET /rest/credentials/new?name=…` avant POST.
Il semble donc que le nommage soit déterminé par (a) le nom de base du frontend + (b) la génération de noms uniques du backend dans /credentials/new.
Cela suggère que la différence provient de la correspondance des noms existants pour chaque préfixe (OpenAI account% vs GAIP account%), plutôt que de save() ou uiContext.
Alors… quelle est la difficulté pour renommer les identifiants ? 
J’utilise n8n depuis environ 4 ans, et j’ai remarqué que laisser le nom de base entraîne des problèmes lors de la mise à jour des identifiants ultérieurement ou de la détermination de ce qui est quoi
il n’y a pas de difficulté, mais c’est confus
C’est normal @Jankaz, une fois que tu trouveras ta façon de comprendre la question, ça deviendra plus facile. Ce n’est pas quelque chose de configurable, elles sont effectivement différentes visuellement.
Je n’ai trouvé aucun paramètre pour modifier la logique de génération automatique de noms
La séparation par utilisateur/projet existe au niveau des permissions et de la visibilité des credentials, via RBAC/Projects, mais cela ne signifie pas que le compteur automatique de noms soit également scopé par projet. La documentation RBAC parle d’accès aux workflows et aux credentials par projet, pas d’algorithme de nommage.
comme suggéré dans le fil, la solution de contournement consiste à nommer manuellement les credentials avec le projet/utilisateur dans le nom.