[CRITICAL] New file inputs broke the file input logic in signed urls

API Bugs
1

Hello, since Feb 23 our production application has broken due to us using presigned-urls for file url inputs, which was working before the new file inputs update. This is critical due to being an issue on OpenAI’s end which can be fixed with our current setup. We have Data retention off, which means we cannot use the File API to store the file in OpenAI servers.

This is the error that appears now

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’}}

2 Likes
2

Hi @Fiath.py, oh yeah, that’s rough, especially if this just started breaking after the Feb 23 changes.

From that error, it looks like the system is now being stricter about how it detects file types. When you pass a presigned URL, it usually relies on the file extension in the URL path itself (not just the actual file contents).

Quick couple things to check:

  • What file type are you sending?
  • Does the presigned URL actually end in something like .pdf, .docx, etc.?
  • Which endpoint are you calling?

Since you’ve got data retention off, I get why using the Files API isn’t workable here. If you can share a sanitized example of the request (just structure, no secrets), that’d help figure out whether this is just extension validation or something deeper that changed.

Let’s see what’s going on, we should be able to narrow it down pretty quickly.

1 Like
3

Sending PDFs

The presigned URL ends with a token, so no extension in there

We are calling the responses endpoint

4

It’s pretty simple to understand: some dumb extension-matching going on, or a failed internal retrieval giving a different body but not noticing an error code.

This is Amazon’s example - this bug report is still missing the exact hosting being used and whether the URL is properly formed with a path and file name with extension before a separate query string sequence.

https://examplebucket.s3.amazonaws.com/test.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=<your-access-key-id>/20130721/us-east-1/s3/aws4_request&X-Amz-Date=20130721T201207Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=<signature-value>

The error message that was provided in the report tells you exactly what’s going on.

Like my attempts to replicate completely timing out on one host I tried.

Here is replication code, filling in the further lack of the report’s mention of how they are providing the URL and to what API method, with an AI-generated query string pattern that might lookalike; it’s successful currently.

from openai import OpenAI; client = OpenAI()

response = client.responses.create(
  model="gpt-5.2",
  input=[
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "I'm giving this PDF. Can you see it and summarize the contents, or is the API so dumb as to not even try?"
        },
        {
            "type": "input_file",
            "file_url": "https://hotnova.com/test1.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIOSFODNN7EXAMPLE%2F20130721%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20130721T201207Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=9f1c2d3e4a5b6c7d8"
            # "file_url": "https://hotnova.com/test1.pdf"
        }
      ]
    }
  ],
  reasoning={
    "effort": "none",
  },
  store=False,
)
print(response.output_text)

OpenAI has used deep file inspection screening, to even deny mis-identified file types that do have the correct file extension in the URL or provided filename.

If you as “support” have got any facility at all to even make an API attempt (instead of merely making botty words and guesses), go at it and make a request - it should be OpenAI’s job to validate against all URL scenarios.

1 Like
5

We are observing similar issues, using signed urls to attach PDFs stopped working with the exact same error response.

A now expired url that has worked just a few days ago is (domain changed for example);

https://example.com/uploads/5de67677-2956-415d-a76b-abdab01db015.pdf?Expires=1771932020&Key-Pair-Id=K3I7VWC0WNYHRM&Signature=XEyZupyMy0gwmCNGzCYCvQUUDYy55fxDB72ZU8cIN7oFMI-WWu4E5bvLqDc4kOCyCceDXOrGzxD6b65pCSyNS7KswEUA4zVJKP~MFqtW8LnKzDERQVxRl4BCETFOmMbP5IdZ2~9QofJmO1MbH2XaP5ZqipSUXT7cMBSR~7sGl4gKobzUy9WvqGJ~pl7phZJF4m7xMlgUtDcN7MB5z64qbM3KZAnxIJnZ8D7UbBuLIxw8mSR40dQZvfoCvKZBZWGkfv-wLFu1aqysQHQpHWeB88wCNqrYqm~AAmvoRR2M6ph35suNg8-j5eemB7LNe8U0vW02aQgps63CuM~2C07f~w__

While one that does not work today is;

https://example.com/uploads/43a97fb3-b70b-4c16-9063-43fd6f28aa6b.pdf?Expires=1772202324&Key-Pair-Id=K3I7VWC0WNYHRM&Signature=eCYZGg0cZhrnMAFspsnANVnL7iWl5k~7Q470OvuWnPJe2a-fVu5sZc50UhzQ2V-rAKHCaK6Te4piIaNeaVhYk0~QO3YX2ETjkcwmYyOFPkLzcDotkXqiTOynexFJbxSjdYxG6FQdNK8chvS3MVSccmdvvoKAvx-XFdr5nYCD1~l-JKQKs9qJQnSHYMwrzt-BIoCIrA3omlPGnZhR22D-~id~kGtkZSw1qaGsIgtGsyi~QmyZbsLlzS9gyRO-uWimNyBYSWBF~hHnvb8m2Z-Gq6qBenr06MaC-KYZiUkSIZTZwW12X30As7g3xnhJrv3Wre4dYRGvjAkIYcZSrwXZgA__

Both links go to the same file, are served through cloudfront, with a s3 origin. Same content, same metadata, no change in our s3 or cloudfront settings.

It is consistent too, I have not been able to get a single signed url to work today while testing, and prior to noticing this today, we have never observed a similar error from signed urls.

I suspect something that changed with the update to the responses api input_file parameter that was made on the 24th of Feb, but that is just my guess.

2 Likes
6

Bump, this is still happening.

Having to pass whole files as base64 now is making our app sluggish.

Please fix this in your end @OpenAI_Support !

1 Like
7

Hi!
This has been escalated to the team.
Fingers crossed that it will be resolved quickly!

1 Like
8

Hi, hopefully not hijacking this thread. We’re seeing similar problems even for non-signed urls. Happy to provide (privately) examples of the json body we’re sending or request ids to help debug the issue.

Thanks!

1 Like
9

@vb Hello!

Any news on this issue? It’s still happening, sending files with base64 encoding is not as effective as sending them as URLs, the file size restrictions is not the same.

As an example we are sending a 19MB pdf sa base64 and now it is not working. We still cannot send it as a signed URL