Responses API now has expanded file input types: docx, pptx, csv, xlsx

API
1

In addition to the new file types, there’s specific file types augmentation for data (xlsx, csv, etc):

Instead of passing entire sheets to the model, the API parses up to the first 1,000 rows per sheet and adds model-generated summary and header metadata so the model can work from a smaller, structured view of the data.

Category Common extensions
PDF files .pdf
Text and code .txt, .md, .json, .html, .xml, code files
Rich documents .doc, .docx, .rtf, .odt
Presentations .ppt, .pptx
Spreadsheets .csv, .xls, .xlsx

Read more:

4 Likes
3

This broke passing pdf urls with queries, like AWS presigned urls https:// my-bucket.s3.amazonaws /order_file/82137_0.pdf?X-Amz-Region-Set=us-east-1,us-west-1&…. (url redacted because I can’t include url in post)

It worked on feb 23, and since feb 24 I get :
openai.BadRequestError: Error code: 400 - {‘error’: {‘message’: ‘The file type you uploaded is not supported. Supported extensions: art, bat, brf, c, cls, css, csv, diff, doc, docx, dot, eml, es, h, hs, htm, html, ics, ifb, java, js, json, keynote, ksh, ltx, mail, markdown, md, mht, mhtml, mjs, nws, odt, pages, patch, pdf, pl, pm, pot, ppa, pps, ppt, pptx, pwz, py, rst, rtf, scala, sh, shtml, srt, sty, svg, svgz, tex, text, txt, vcf, vtt, wiz, xla, xlb, xlc, xlm, xls, xlsx, xlt, xlw, xml, yaml, yml’, ‘type’: ‘invalid_request_error’, ‘param’: ‘input’, ‘code’: ‘unsupported_file’}}

The file is a PDF, with pdf mime type

I have the errors on all files in production, and never had that before feb 24

I temporarily fixed it by using the file.create API and passing a file_id, but I prefered passing a URL

1 Like
4

Thank you for this update! Is it possible to have a bit more details on how the attachments ends up being “attached” to the user prompt?

In my tests, they seem to be simply appended to the user text, without filename (see Input_file unreliable on inlined (data:) content (post 2026-02 update) - API / Bugs - OpenAI Developer Community).
While filename appears to be used in file type detection, the metadata does not appear to be provided to the prompt, and the llm does not seem to be aware it is dealing with an attachment. Any additional details would help us understand pitfalls to avoid (ex. if text files are simply appended, they pose a different prompt injection threat than if they are handled as first class file attachments)

Also, the documentation at File inputs | OpenAI API should probably be a bit more precise for Base64 - where it says:

                "content": [
                    {
                        "type": "input_file",
                        "filename": "draconomicon.pdf",
                        "file_data": "...base64 encoded PDF bytes here..."
                    },

the "file_data": "...base64 encoded PDF bytes here..." should probably clarify that the format is actually data:application/pdf;base64,base64 encoded PDF bytes here

1 Like
5

It is attached with `{“type”: “input_file”, “file_url”: order_file_signed_url},`
I guess filename should be infered from file_url ? Or should I provide both ?