L’erreur {"message":"DELETE method not allowed"} indique que bien que le serveur ait reconnu votre URL, il a rejeté la requête DELETE car le point de terminaison spécifique ne supporte pas cette méthode HTTP. La cause la plus courante est que votre credentialID n’est pas correctement substitué — si vous envoyez la chaîne littérale {credentialID} au lieu de l’ID d’authentification réel, n8n traite la requête comme un appel à la collection d’authentifiants (/api/v1/credentials) plutôt qu’à un authentifiant spécifique (/api/v1/credentials/123), et la méthode DELETE n’est pas disponible sur le point de terminaison de collection.
Vous devrez probablement vérifier que votre UUID d’authentifiant réel ou votre ID numérique est présent dans l’URL. Si les appels directs à l’adresse IP et au port fonctionnent mais échouent derrière un proxy, votre configuration de proxy inverse (comme Nginx) pourrait bloquer les requêtes DELETE. Assurez-vous d’utiliser l’en-tête d’authentification correct (X-N8N-API-KEY), et essayez de contourner votre couche de proxy pour tester si le problème provient de la requête de méthode elle-même ou de votre configuration de proxy.
Le 405 provient de la spécification API publique livrée avec la version 2.39.2, pas de votre ID. Dans cette spécification, DELETE est déclaré sous /credentials/{id}, tandis que la même URL est également déclarée comme /credentials/{credentialId} avec GET uniquement, et le validateur de requête qu’utilise n8n répond à DELETE avec son propre 405 « DELETE method not allowed ».
J’ai exécuté les spécifications publiées via la version du validateur dont dépend 2.39.2 (express-openapi-validator 5.5.3) : les versions 2.39.2 et 2.39.8 retournent le même 405 et message que vous avez reçu, à la fois pour un ID d’apparence réelle et pour un littéral {credentialID}, et à partir de 2.39.9, les deux chemins sont fusionnés et DELETE passe. C’était le validateur avec la spécification de chaque version, pas une instance complète de n8n, donc je sauvegarderais Postgres, déplacerais l’image vers 2.39.10 (la plus récente 2.39.x) et essayerais le même appel.
DELETE /api/v1/credentials/{id} est pris en charge dans n8n 2.39.2. L’utilisation d’un ID incorrect ne transforme pas cette URL en une requête vers le point de terminaison de la collection /credentials.
Pourrais-tu partager la requête réelle en cURL avec les secrets supprimés, ainsi que le code de statut HTTP et les en-têtes de réponse ? Merci d’inclure l’URL après que toutes les variables aient été résolues. Cela nous aidera à vérifier le chemin exact appelé et d’où provient la réponse.
405 signifie que la requête n’a jamais atteint la vérification d’authentification : n8n répond « méthode non autorisée » lorsque la route existe mais n’enregistre pas ce verbe, donc une X-N8N-API-KEY fonctionnelle est attendue ici et ce n’est pas le problème.
Deux tests différentiels le confirment :
GET la même URL avec la même clé. Si GET retourne les identifiants, le routage fonctionne et votre build n’expose simplement pas DELETE sur /api/v1/credentials/{id} (les anciennes versions ne contenaient que GET/POST/PATCH) - vérifiez ensuite la version dans Paramètres > À propos (ou n8n --version) et supprimez via l’interface jusqu’à ce que vous fassiez la mise à niveau.
Si GET retourne également 405, quelque chose devant :5678 (proxy inverse, passerelle API, tunnel) rejette le verbe, et aucune modification à l’intérieur de n8n ne pourra aider.
Sur une build antérieure au point de terminaison, la route REST interne DELETE /rest/credentials/{id} fonctionne avec un cookie de session du navigateur, mais ce n’est pas l’API publique et votre clé API ne l’authentifiera pas.
Essayez le même DELETE avec curl sur l’hôte docker contre localhost:5678 avec votre en-tête X-N8N-API-KEY, ce qui contourne tout ce qui se trouve devant n8n. Si ça fonctionne là, un proxy ou un firewall bloque probablement DELETE. Y a-t-il nginx ou une passerelle quelconque entre vous et le conteneur ?
Nous avons examiné cela et il semble que cela pourrait être corrigé dans une version récente. Veuillez mettre à jour et vérifier si vous rencontrez toujours le même problème.
Nous avons examiné cela et il semble que cela pourrait être corrigé dans une version récente. Veuillez mettre à jour et vérifier si vous rencontrez toujours le même problème.