OpenAI Node - "Enviar mensaje a un modelo" (v2 Actions) - Solicitud incorrecta - por favor verifica tus parámetros

Preguntas
1

Describe el problema/error/pregunta

Parece haber una regresión @Bug en la última versión del nodo nativo de OpenAI (2.3 (Latest)) al usar el nuevo diseño v2 Actions. Específicamente, al seleccionar Resource: Text → Operation: Message a Model y configurar el Output Format a JSON Schema u JSON Object, el nodo falla completamente en la ejecución.
La llamada API de fondo falla con un error 400 Bad Request de OpenAI.

Mensaje de error:

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

Las directrices de la API de OpenAI dictan que espera estrictamente output_text o refusal en este nivel del array del objeto payload.

Lo que hicimos para probar y aislar el problema:

  1. Probamos los Toggles de Formato de Salida: Intentamos cambiar de JSON Schema (recommended) a un básico JSON Object para eliminar la aplicación estricta de esquemas. El error seguía ocurriendo, mostrando que la capa wrapper de tool-calling/chat de fondo de n8n está codificando o forzando el parámetro input_text independientemente del formato elegido.

  2. Probamos Soluciones Alternativas de Rol de Mensaje: Intentamos combinar las entradas del usuario y las reglas del sistema en un único bloque de mensaje System para evitar que n8n cree parámetros de array de rol User anidados. El nodo seguía forzando la configuración de payload inválida.

  3. Verificamos a través del Nodo HTTP Request: Para probar que el problema era un bug de formateo del nodo n8n y no una interrupción de la API de OpenAI o un mal diseño de prompt, codificamos manualmente la solicitud usando un estándar Nodo HTTP Request dirigido a https://api.openai.com/v1/chat/completions con exactamente el mismo payload. Se ejecutó y analizó el JSON perfectamente.

La Solución que Funciona / Solución Alternativa:

Como prueba definitiva, copiamos una versión más antigua de la integración de OpenAI (Node Version 1.4) de un flujo de trabajo heredado al lienzo. Usando la estructura del nodo versión 1.4 heredada con el prompt idéntico, parámetros y datos de entrada, el flujo de trabajo se ejecuta sin problemas. Esto señala un bug en cómo la Versión de Nodo 2.3 maneja la representación del payload para los endpoints más nuevos de la API de Respuestas de OpenAI.

¿Cuál es el mensaje de error (si hay alguno)?

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

Por favor comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte la salida devuelta por el último nodo

{
“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"
]
}
}

Información sobre tu configuración de n8n

  • Versión n8n: 2.23.4 (Self Hosted)
  • Base de datos (predeterminado: SQLite):
  • Configuración n8n EXECUTIONS_PROCESS (predeterminado: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, desktop app): Docker - Self-hosted
  • Sistema operativo:
2

@bridgewaretech aislamiento sólido. La causa raíz es el tipado de contenido de la API de Responses: los mensajes con rol de asistente deben usar output_text, solo user/developer usan input_text. Tu input[2] es un mensaje de asistente (un turno anterior o un subnodo de memoria de chat adjunto) que v2.3 etiqueta como input_text, de ahí el 400.

Dato útil: solo se dispara cuando hay un mensaje de asistente en la entrada, así que eliminar un subnodo de memoria/historial de ese nodo lo evita (no es viable si necesitas contexto, pero confirma el desencadenante). v1.4 lo evita usando chat/completions en su lugar, así que esa y tu solución HTTP son las interim correctas.

Regresión conocida de v2-node, vale la pena añadir tu reproducción limpia a un issue de GitHub en n8n-io/n8n si no hay uno abierto.

3

Gracias @achamm
Ya hemos añadido el problema a GitHub.

4

@bridgewaretech ¡De nada! Siéntete libre de marcar una de las respuestas como la solución y ¡que tengas un excelente día! ¡Ojalá se solucione! ¿También puedes enviar el enlace del problema?

5

:police_car_light: Actualización del Desarrollador / Estado de GitHub

Una actualización rápida sobre este tema. Reportamos el bug directamente a los desarrolladores en GitHub, y han reconocido el problema. [Enlace de Github aquí]

Aquí está la nota/actualización del desarrollador:

Causa raíz: la operación v2 “Message a Model” construye cada mensaje de texto con una parte de contenido input_text, independientemente del rol. La API de Responses de OpenAI solo acepta output_text/refusal para mensajes con rol assistant, por lo que tan pronto como hay un mensaje de Assistant en la lista, la solicitud falla con:

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

El Formato de Salida (JSON Schema / JSON Object) no es realmente el desencadenante — es el mensaje con rol de Assistant siendo enviado como input_text. El nodo legacy 1.4 funciona porque se dirige al endpoint chat/completions más antiguo, que no utiliza estas partes de contenido tipadas.

Solución: los mensajes de texto del asistente se enviarán como contenido de cadena simple (que la API de Responses acepta y trata como texto de salida del asistente) en lugar de una parte input_text; los mensajes de usuario/sistema no cambian. Un PR con este cambio más pruebas de regresión está en camino y se vinculará aquí.

Soluciones alternativas hasta que se lance:

  • Elimina el/los mensaje(s) con rol de Assistant e integra ese contexto en el mensaje System, o
  • Usa el nodo HTTP Request (o el nodo 1.4) que ya verificaste que funciona.

:police_car_light: Actualización del Desarrollador / Estado de GitHub

Según la actualización de desarrollo, la solución se lanzó con n8n@2.29.0