OpenAI Node - "Message a Model" (v2 Actions) - Bad request - please check your parameters

Questions
1

Describe the problem/error/question

There appears to be a regression @Bug in the latest version of the native OpenAI node (2.3 (Latest)) when using the new v2 Actions layout. Specifically, when selecting Resource: Text → Operation: Message a Model and configuring the Output Format to either JSON Schema or JSON Object, the node completely fails on execution.
The background API call crashes with a 400 Bad Request error from OpenAI.

Error message:

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

OpenAI’s API guidelines dictate that it strictly expects output_text or refusal at this level of the payload object array.

What we did to test and isolate the issue:

  1. Tested Output Format Toggles: We tried switching from JSON Schema (recommended) to a basic JSON Object to remove strict schema enforcement. The error still occurred, showing that n8n’s background tool-calling/chat wrapper layer is hardcoding or forcing the input_text parameter regardless of the format chosen.

  2. Tested Message Role Workarounds: We tried combining the user inputs and system rules into a single System message block to prevent n8n from creating nested User role array parameters. The node still forced the invalid payload configuration.

  3. Verified via HTTP Request Node: To prove the issue was an n8n node formatting bug and not an OpenAI API outage or bad prompt design, we manual-coded the request using a standard HTTP Request Node targeting https://api.openai.com/v1/chat/completions with the exact same payload. It executed and parsed the JSON perfectly.

The Working Solution / Workaround:

As a definitive test, we copied an older version of the OpenAI integration (Node Version 1.4) from a legacy workflow into the canvas. Using the legacy version 1.4 node structure with the identical prompt, parameters, and input data, the workflow runs flawlessly. This points to a bug in how Node Version 2.3 handles payload rendering for OpenAI’s newer Responses API endpoints.

What is the error message (if any)?

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

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

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

Information on your n8n setup

  • n8n version: 2.23.4 (Self Hosted)
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker - Self-hosted
  • Operating system:
2

@bridgewaretech solid isolation. Root cause is Responses API content typing: assistant-role messages must use output_text, only user/developer use input_text. Your input[2] is an assistant message (a prior turn or an attached chat-memory sub-node) that v2.3 tags as input_text, hence the 400.

Useful tell: it only fires when an assistant message is in the input, so dropping a memory/history sub-node from that node dodges it (not viable if you need context, but it confirms the trigger). v1.4 avoids it by hitting chat/completions instead, so that and your HTTP workaround are the right interim.

Known v2-node regression, worth adding your clean repro to a GitHub issue on n8n-io/n8n if one isn’t open.

3

Thanks @achamm
We added the issue to GitHub already.

4

@bridgewaretech Your welcome! Feel free to mark one of the replies as the solution and have a great day! Hopefully this gets fixed! Can you also send the issue link?

5

:police_car_light: Update from Developer / GitHub Status

A quick update on this topic. We raised the bug directly with the developers on GitHub, and they have acknowledged the issue. [Github Link here]

Here is the note/update from the developer:

Root cause: the v2 “Message a Model” operation builds every text message with an input_text content part, regardless of role. OpenAI’s Responses API only accepts output_text/refusal for assistant-role messages, so as soon as an Assistant message is in the list, the request fails with:

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

The Output Format (JSON Schema / JSON Object) isn’t actually the trigger — it’s the Assistant-role message being sent as input_text. The legacy 1.4 node works because it targets the older chat/completions endpoint, which doesn’t use these typed content parts.

Fix: assistant text messages will be sent as plain string content (which the Responses API accepts and treats as assistant output text) instead of an input_text part; user/system messages are unchanged. A PR with this change plus regression tests is on the way and will be linked here.

Workarounds until it ships:

  • Remove the Assistant-role message(s) and fold that context into the System message, or
  • Stick with the HTTP Request node (or the 1.4 node) you already verified works.

:police_car_light: Update from Developer / GitHub Status

As per development update, Fix got released with n8n@2.29.0