Response API system role returns 400 on file_input

I have some persona support files I am trying to add to a conversation via the responses API, but I get a 400 error that seems to indicate that the only valid input type for it is text_input. Is that correct? I’m trying to add it to a system role content, but I hope this doesn’t mean it won’t accept files for any roles (I’m using file id’s from OpenAI’s file storage) via the response API.

This AI responding to posts on the forum is merely repeating back what it sees in the first post content without first-hand knowledge. The entire forum account is a bot in violation of OpenAI terms that impersonating people without disclosure is not allowed.

We can see that blind inference when AI masquerading as human parrots back “text_input” or “file_input” at the poster, which is not the correct field name to send to the API at all. Also, ambiguous echoes about “file ids” or “tool-related inputs” without knowing what those actually could be.


You can explore the Responses’ API reference, expand “input” (multiple times), and see the true type names that can be placed in a content list. Unfortunately, this structure originating in the OpenAPI specification doesn’t validate vs role unlike the way the Chat Completions API reference is laid out in terms of what you can send per role type.

Here’s a deep link: https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-input_message-content-input_item_content_list

Short answer: only “user” only has "type":"input_file" alongside image inputs, and that input content type only supports PDF files for full context extraction and placement.

For a non-varying top-level developer “instructions”, don’t make API extract the same PDF text and images for every repeated call - such wastefulness is already blocked.

Endpoint-specific: “instructions” field in an API request is where instructions should be, only text, to not be pushed out of large input context. Plus, even if you do your own file text extraction, don’t allow user injection of their files in this elevated “developer” context.

I’m doing some experiments with making use of 4.1’s massive context window. I understand about how ‘wasteful’ this is. Especially from the usual developer perspective. This is for experimental purposes. It’s unfortunate, in my opinion, that it’s precluded. I also tried to use these files under the user role designated for the purpose of “user data” and got the same error.

I hope I just screwed up, because with my extreme TPM limits, what I’m trying to do is going to be a pain in the butt. It’s also unfortunate that the API documentation doesn’t actually call this out. I made choices based on the documentation. And, yes, I know that the reality of an API and it”s documentation seldom truly align, but if this truly is a user role only functionality, it certainly didn’t seem clear in any documentation I have read.

And I’m happy to say, I screwed up. I was overly tired and missed something. A couple of things, actually. As long as it’s for the user role and a PDF, it does accept the files as input. Yeah!

1 Like