OpenAI Node - "Enviar mensagem para um Modelo" (v2 Actions) - Solicitação inválida - verifique seus parâmetros

Descreva o problema/erro/pergunta

Parece haver uma regressão @Bug na versão mais recente do nó nativo OpenAI (2.3 (Mais recente)) ao usar o novo layout v2 Actions. Especificamente, ao selecionar Resource: Text → Operation: Message a Model e configurar o Output Format para JSON Schema ou JSON Object, o nó falha completamente na execução.
A chamada de API em segundo plano falha com um erro 400 Bad Request do OpenAI.

Mensagem de erro:

Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.

As diretrizes de API do OpenAI determinam que ele espera estritamente output_text ou refusal neste nível do array do objeto payload.

O que testamos para isolar o problema:

  1. Testamos alternâncias de Output Format: Tentamos alternar de JSON Schema (recomendado) para um básico JSON Object para remover a aplicação rigorosa de esquema. O erro ainda ocorreu, mostrando que a camada de wrapper de tool-calling/chat em segundo plano do n8n está codificando ou forçando o parâmetro input_text independentemente do formato escolhido.

  2. Testamos soluções alternativas de Message Role: Tentamos combinar as entradas do usuário e as regras do sistema em um único bloco de mensagem System para evitar que o n8n criasse parâmetros de array com função User aninhados. O nó ainda forçou a configuração de payload inválida.

  3. Verificamos via HTTP Request Node: Para provar que o problema era um bug de formatação de nó do n8n e não uma interrupção de API do OpenAI ou design de prompt ruim, codificamos manualmente a solicitação usando um HTTP Request Node padrão direcionado para https://api.openai.com/v1/chat/completions com o payload exatamente igual. Executou e analisou o JSON perfeitamente.

A Solução Funcionando / Solução Alternativa:

Como teste definitivo, copiamos uma versão mais antiga da integração OpenAI (Node Version 1.4) de um workflow legado para a tela. Usando a estrutura do nó versão 1.4 legada com o prompt idêntico, parâmetros e dados de entrada, o workflow executa perfeitamente. Isso aponta para um bug em como a Node Version 2.3 trata a renderização de payload para os endpoints mais novos da API de Respostas do OpenAI.

Qual é a mensagem de erro (se houver)?

Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.

Por favor, compartilhe seu workflow

(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)

Compartilhe a saída retornada pelo último nó

{
“errorMessage”: “Bad request - please check your parameters”,
“errorDescription”: “Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.”,
“errorDetails”: {
“rawErrorMessage”: [
“400 - {"error":{"message":"Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.","type":"invalid_request_error","param":"input[2].content[0]","code":"invalid_value"}}”
],
“httpCode”: “400”
},
“n8nDetails”: {
“nodeName”: “Create post and image”,
“nodeType”: “@n8n/n8n-nodes-langchain.openAi”,
“nodeVersion”: 2.3,
“resource”: “text”,
“operation”: “response”,
“itemIndex”: 0,
“time”: “17/06/2026, 1:41:31 pm”,
“n8nVersion”: “2.23.4 (Self Hosted)”,
“binaryDataMode”: “filesystem”,
“stackTrace”: [
“NodeApiError: Bad request - please check your parameters”,
" at ExecuteContext.requestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/node-execution-context/utils/request-helper-functions.ts:1368:10)“,
" at processTicksAndRejections (node:internal/process/task_queues:104:5)”,
" at ExecuteContext.requestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/node-execution-context/utils/request-helper-functions.ts:1711:11)“,
" at ExecuteContext.apiRequest (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/transport/index.ts:56:19)”,
" at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/v2/actions/text/response.operation.ts:621:18)“,
" at ExecuteContext.router (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/v2/actions/router.ts:58:25)”,
" at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/v2/OpenAiV2.node.ts:93:10)“,
" at WorkflowExecute.executeNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1053:9)”,
" at WorkflowExecute.runNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1327:11)“,
" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1778:27”,
" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2426:11"
]
}
}

Informações sobre sua configuração n8n

  • Versão n8n: 2.23.4 (Self Hosted)
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, desktop app): Docker - Self-hosted
  • Sistema operacional:

@bridgewaretech isolamento sólido. A causa raiz é a digitação de conteúdo da API Responses: mensagens com papel de assistente devem usar output_text, apenas user/developer usam input_text. Seu input[2] é uma mensagem de assistente (um turno anterior ou um subnó de memória de chat anexado) que v2.3 marca como input_text, daí o erro 400.

Dica útil: ele só dispara quando uma mensagem de assistente está na entrada, então remover um subnó de memória/histórico daquele nó contorna isso (não é viável se você precisa de contexto, mas confirma o gatilho). v1.4 evita isso acessando chat/completions em vez disso, então essa e sua solução HTTP são as corretas para interim.

Regressão conhecida do v2-node, vale a pena adicionar sua reprodução limpa a uma issue do GitHub em n8n-io/n8n se uma não estiver aberta.

Obrigado @achamm
Já adicionamos a issue no GitHub.

@bridgewaretech De nada! Fique à vontade para marcar uma das respostas como solução e tenha um ótimo dia! Esperamos que isso seja resolvido! Você também pode enviar o link da issue?

:police_car_light: Atualização do Desenvolvedor / Status do GitHub

Uma atualização rápida sobre este tópico. Reportamos o bug diretamente aos desenvolvedores no GitHub, e eles reconheceram o problema. [Link do Github aqui]

Aqui está a nota/atualização do desenvolvedor:

Causa raiz: a operação v2 “Message a Model” constrói cada mensagem de texto com uma parte de conteúdo input_text, independentemente da função. A API de Respostas do OpenAI apenas aceita output_text/refusal para mensagens com função assistant, portanto, assim que uma mensagem de Assistente estiver na lista, a solicitação falha com:

Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.

O Formato de Saída (JSON Schema / JSON Object) não é realmente o gatilho — é a mensagem com função Assistant sendo enviada como input_text. O nó legado 1.4 funciona porque é direcionado ao endpoint chat/completions mais antigo, que não usa essas partes de conteúdo digitadas.

Correção: mensagens de texto de assistente serão enviadas como conteúdo de string simples (que a API de Respostas aceita e trata como saída de assistente) em vez de uma parte input_text; mensagens de usuário/sistema não foram alteradas. Um PR com essa alteração e testes de regressão está a caminho e será vinculado aqui.

Soluções alternativas até ser lançado:

  • Remova a(s) mensagem(ns) com função Assistant e integre esse contexto na mensagem do Sistema, ou
  • Continue usando o nó HTTP Request (ou o nó 1.4) que você já verificou funcionar.

:police_car_light: Atualização do Desenvolvedor / Status do GitHub

Conforme a atualização de desenvolvimento, a Correção foi lançada com n8n@2.29.0