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

[bridgewaretech]

Bug Description

There appears to be a regression 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:
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.

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.

To Reproduce

1. Create a workflow where you add the latest OpenAI "Message a model" node.
2. Selecting Resource: Text → Operation: Message a Model
3. Add the message for the User Role, System Role and Assistant Role.
4. Configuring the Output Format to either JSON Schema or JSON Object.
5. Node completely fails on execution. The background API call crashes with a 400 Bad Request error from OpenAI.

Expected behavior

Node should execute with no error and generate the JSON output.
The background API call should not crash with a 400 Bad Request error from OpenAI.

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.

Debug Info

Debug info

core

• n8nVersion: 2.23.4
• platform: docker (self-hosted)
• nodeJsVersion: 24.15.0
• nodeEnv: production
• database: sqlite
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: d7001eab-098b-4417-b831-3fa35af19068

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: filesystem

pruning

• enabled: true
• maxAge: 336 hours
• maxCount: 10000 executions

client

• userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/149.0.0.0 safari/537.36 edg/149.0.0.0
• isTouchDevice: false

cluster

• instanceCount: 1
• versions: 2.23.4
• instances:
  • instanceKey: 0ca51285-8e23-43a8-97a2-6dcbd29c1408, hostId: main-e8a942bdb100, instanceType: main, instanceRole: leader, version: 2.23.4
• checks:
  • check: hostid-clash, status: succeeded, warnings: -
  • check: lifecycle, status: succeeded, warnings: -
  • check: split-brain, status: succeeded, warnings: -
  • check: version-mismatch, status: succeeded, warnings: -

Generated at: 2026-06-17T05:53:42.665Z

Operating System

Ubuntu Linux

n8n Version

2.23.4

Node.js Version

24.15.0

Database

SQLite (default)

Execution mode

main (default)

Hosting

self hosted

[Lakshya77089]

Thanks for the detailed write-up — the HTTP Request comparison and the v1.4 fallback were exactly the clues needed. You've correctly isolated it to the v2 node's payload formatting.

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.

If you have a moment, could you confirm whether removing the Assistant-role message alone (keeping JSON output) makes it pass on 2.23.4? That would confirm the assistant message is the sole trigger on your end.

[Lakshya77089]

PR is up: #32464

[n8n-assistant]

Hey @bridgewaretech,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-8731".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-8731

[bridgewaretech]

If you have a moment, could you confirm whether removing the Assistant-role message alone (keeping JSON output) makes it pass on 2.23.4? That would confirm the assistant message is the sole trigger on your end.

Hi @Lakshya77089
Thanks for looking into this. We just ran a quick test, and we can confirm removing the Assistant-role message alone (keeping JSON output) makes it pass on 2.23.4.

Since we had to upgrade our n8n instance to 2.26.6 to resolve other issues, we also tested the same OpenAI node and it also passed when removing the Assistant-role message.

Thanks again.

[n8n-assistant]

Fix got released with n8n@2.29.0