Olá a todos,
Estou enfrentando um problema estranho com o HTTP Request do n8n.
Ambiente
n8n Self Hosted 2.20.11
Nó HTTP Request v4.4
API externa usando autenticação JWT Bearer
O que acontece
Chamo o endpoint de Autorização da API a partir do n8n.
A API retorna um token JWT válido.
Uso esse token exato em um segundo nó HTTP Request.
A API responde com:
{
“result”: “error”,
“description”: “No valid key”
}
Status HTTP: 401
Importante
O mesmo token copiado manualmente do n8n para o Postman funciona corretamente.
O provedor da API verificou o endpoint e as credenciais.
O cURL exato exportado do Postman foi importado para um novo nó HTTP Request e ainda falha no n8n.
Opção Lowercase Headers testada.
Configurações de Gzip / compressão testadas.
Accept-Encoding: identity testado.
O cabeçalho Authorization é enviado como:
Authorization: Bearer
O fornecedor da API testou a mesma solicitação do Postman com o mesmo token e recebe:
{
“result”: “ok”,
“idlead”: “5”
}
Alguém já viu um caso em que o n8n envia algo diferente do Postman mesmo ao importar o cURL exato?
Alguma ideia sobre como inspecionar a solicitação de saída bruta do n8n seria apreciada.
Obrigado.
@Hector_AnVa forma mais rápida de ver exatamente o que n8n envia (exatamente o que você pediu): aponte ambos para um inspetor de requisições. pegue uma URL do webhook.site, configure o nó do n8n E sua requisição do Postman para acessá-la, dispare ambas, faça um diff dos headers capturados. isso sempre expõe a diferença.
você já descartou maiúsculas/gzip, então os dois culpados habituais:
Authorization duplicada. se a autenticação do nó está configurada com uma credencial E também há um header Authorization manual (a importação cURL frequentemente adiciona um), n8n envia dois e a api retorna 401, mantenha exatamente um.
headers padrão do n8n, ele adiciona um User-Agent e às vezes Accept-Encoding que o Postman não tem, e gateways rigorosos rejeitam por isso.
já que até o cURL importado falha, minha aposta é na Authorization duplicada, o diff do webhook.site confirma em 30 segundos.
Para ver exatamente o que o n8n está enviando, use um serviço de inspeção de requisições. Esta é a forma mais confiável de comparar a requisição do n8n com a requisição do Postman.
Acesse Webhook.site e copie a URL única fornecida.
Altere a URL do seu segundo nó HTTP Request para esta URL do Webhook.site.
Execute o nó.
Inspecione os headers e o body na interface do Webhook.site.
O que procurar: Verifique se Authorization está sendo codificado em dupla, se há espaços em branco extras presentes, ou se o Content-Type é diferente do que sua API espera.
O “Authentication: Predefined Credential Type” do n8n pode às vezes adicionar headers que entram em conflito com seu header Authorization adicionado manualmente. Certifique-se de que você não está acidentalmente enviando dois headers Authorization.
Teste: Defina o dropdown Autenticação como “None” e use estritamente um parâmetro Header nomeado Authorization com o valor Bearer <TOKEN>.
Se você estiver passando o token por meio de uma expressão (por ex., {{ $json.token }}), certifique-se de que não haja quebras de linha finais ou espaços ocultos sendo capturados do nó anterior. Tente cortá-lo: {{ $json.token.trim() }}.
Algumas APIs bloqueiam requisições com base no header User-Agent padrão do axios (geralmente axios/x.x.x). Tente adicionar um header User-Agent personalizado (por ex., Mozilla/5.0...) para imitar um navegador.
Certifique-se de que o header Accept está explicitamente definido (por ex., application/json), pois algumas APIs se comportam de forma diferente se o */* padrão for enviado.
Complementando a dica do @kjooleng sobre Webhook.site: Uma causa muito comum exatamente para esse padrão (token funciona no Postman, token idêntico falha no n8n) é um espaço em branco invisível ou uma quebra de linha no final do token, que é inserida ao copiar da primeira resposta HTTP para o n8n.
Especificamente para verificar: No primeiro nó HTTP Request que retorna o JWT, examine a saída com cuidado, de preferência através do nó Code com JSON.stringify($json.token) em vez da visualização normal. Se "\n" ou espaços adicionais aparecerem no final, essa é a causa. O Postman frequentemente remove automaticamente ao colar manualmente, o n8n não faz isso.
A solução seria então adicionar um .trim() no campo do token antes de passar para a segunda requisição, seja através de um nó Code ou diretamente no campo Expression: {{ $json.token.trim() }}.