O erro {"message":"DELETE method not allowed"} indica que, embora o servidor tenha reconhecido sua URL, ele rejeitou a solicitação DELETE porque o endpoint específico não suporta esse método HTTP. A causa mais comum é que seu credentialID não está sendo substituído corretamente — se você estiver enviando a string literal {credentialID} em vez do ID de credencial real, o n8n trata a solicitação como uma chamada para a coleção de credenciais (/api/v1/credentials) em vez de uma credencial específica (/api/v1/credentials/123), e o método DELETE não está disponível no endpoint da coleção.
Você provavelmente precisa verificar se o UUID ou ID numérico real de sua credencial está presente na URL. Se as chamadas diretas para o IP e porta funcionam, mas falham atrás de um proxy, sua configuração de proxy reverso (como Nginx) pode estar bloqueando solicitações DELETE. Certifique-se de estar usando o cabeçalho de autenticação correto (X-N8N-API-KEY) e tente contornar qualquer camada de proxy para testar se o problema está com a solicitação do método em si ou com sua configuração de proxy.
O 405 vem da especificação pública da API fornecida com a versão 2.39.2, não do seu ID. Nessa especificação, DELETE é declarado sob /credentials/{id}, enquanto a mesma URL também é declarada como /credentials/{credentialId} apenas com GET, e o validador de solicitações que n8n usa responde DELETE com seu próprio 405 “DELETE method not allowed”.
Executei as especificações publicadas através da versão do validador que 2.39.2 depende (express-openapi-validator 5.5.3): 2.39.2 e 2.39.8 retornam o mesmo 405 e mensagem que você obteve, tanto para um ID com aparência real quanto para um {credentialID} literal, e a partir de 2.39.9 os dois caminhos são mesclados e DELETE passa. Isso foi o validador com a especificação de cada versão, não uma instância n8n completa, então faria backup do Postgres, moveria a imagem para 2.39.10 (a mais recente 2.39.x) e tentaria a mesma chamada.
DELETE /api/v1/credentials/{id} é suportado no n8n 2.39.2. Usar um ID incorreto não transforma essa URL em uma requisição para o endpoint da coleção /credentials.
Poderia compartilhar a requisição real como cURL com segredos removidos, além do status HTTP e dos cabeçalhos de resposta? Por favor, inclua a URL após todas as variáveis terem sido resolvidas. Isso ajudará a verificar o caminho exato sendo chamado e de onde a resposta vem.
405 significa que a requisição nunca chegou à verificação de autenticação: n8n responde “método não permitido” quando a rota existe mas não registra esse verbo, então uma X-N8N-API-KEY funcional é esperada aqui e não é o problema.
Dois testes diferenciais resolvem:
Faça um GET na mesma URL com a mesma chave. Se GET retornar a credencial, o roteamento está correto e sua compilação simplesmente não expõe DELETE em /api/v1/credentials/{id} (versões antigas só forneciam GET/POST/PATCH) - então verifique a versão em Settings > About (ou n8n --version) e delete pela UI até atualizar.
Se GET também retorna 405, algo na frente de :5678 (proxy reverso, gateway de API, túnel) está rejeitando o verbo, e nenhuma alteração dentro de n8n vai ajudar.
Em uma compilação anterior ao endpoint, a rota REST interna DELETE /rest/credentials/{id} funciona com um cookie de sessão do navegador, mas não é a API pública e sua chave de API não a autenticará.
Tente o mesmo DELETE com curl no host docker contra localhost:5678 com seu header X-N8N-API-KEY, isso pula qualquer coisa na frente do n8n. Se funcionar lá, um proxy ou firewall provavelmente está bloqueando DELETE. Há nginx ou algum gateway entre você e o container?
Analisamos isso e parece que pode ter sido corrigido em uma versão recente. Por favor, atualize e veja se você ainda está enfrentando o mesmo problema.