Batch images edits failing with 401 Unable to authorize file access

API Bugs
, , ,
1

I have been using the gpt-image-2 Batch API for image edits for about 3 months without issues. Today, the same workflow suddenly started failing with a 401 error:
“Unable to authorize file access”

My workflow is:

  1. Upload an image file and get an image file ID.
  2. Create an image edit batch JSONL request that references this image file ID.
  3. Upload the JSONL request file and get a request file ID.
  4. Create a Batch API request using that request file ID.

The uploaded image file is successfully created with purpose=“vision” and status=“processed”.
I can retrieve the file metadata using the same API client, so the file appears to exist and be accessible from the Files API. I also checked my storage and there is still plenty of room.

Other APIs still work normally:

  • Text API works.
  • Text Batch API works.
  • Image API works.
  • Image Batch API works when using image_url.

The failure only happens when the Image Batch API references an uploaded image file ID.
Is there any recent change or issue affecting file_id access for image edit batches?

2

Hi and welcome to the community!

Thank you for raising this!
It appears there’s an issue with the Batch API resolving uploaded file_id references.

I will ask the team to take a look.

3

Confirming the same failure here, starting today (2026-08-19). Same setup: gpt-image-2, /v1/images/edits submitted through the Batch API, source image referenced by file_id inside the images array. This had been running in production for months; the first failing batch on my side was created at 10:17 UTC today and came back with 10/10 requests failed:

{"status_code": 401, "request_id": "4fc45244-1ef4-43e9-9450-6ca2b075cd7e",
 "body": {"error": {"message": "Unable to authorize file access.",
 "type": "invalid_request_error", "param": null, "code": null}}}

Note the batch itself reports status: completed with output_file_id: null — everything is in the error file.

To narrow it down I submitted a single batch whose four lines differ only in how the image is referenced. Same account, same key, same image, same minute (batch_6a858b098040819095d49d5974accb97, created 10:52:57 UTC):

line reference shape upload purpose result
A images: [{file_id}] vision 401 Unable to authorize file access. (req edf243a4-189f-4e33-ae22-ed399b7d1d1b)
B images: [{file_id}] user_data 401 Unable to authorize file access. (req cee07f0a-c9fd-4da0-a6e0-78f9bb5d1d73)
C image: {file_id} vision 400 Unknown parameter: ‘image’. For application/json on /v1/images/edits, use ‘images’ (array).
D input_reference: {file_id} vision 400 Missing required parameter: ‘images’.

So the upload purpose makes no difference, and line C’s own error confirms that the images array is the expected shape for JSON requests — i.e. the failing requests are formatted correctly.

A second batch with the image inline instead (batch_6a858bd44a448190864ceac42a29a596, created 10:56:20 UTC):

line reference shape result
E images: [{image_url: "data:image/png;base64,…"}] 200, image returned
F images: ["data:image/png;base64,…"] 400 Invalid type for ‘images[0]’: expected an object, but got a string

One more data point that may help isolate it: the uploaded file is perfectly healthy as far as the Files API is concerned. GET /v1/files/{id}/content returns the exact PNG with the same key that created the batch, both before and after the failing batch runs. A file that has actually been deleted returns No such File object instead, which is a different error than the 401 above. That lines up with VeitB’s note that the Batch API’s resolution of uploaded file_id references is what’s broken.

The image_url workaround does work, but it is materially more expensive for image-guided batches: with file_id the source is uploaded once and referenced by every request; inline, each request line carries its own base64 copy (~1.33× the PNG). For an N-variant round over one source image that turns a single ~1.5 MB upload into N × ~2 MB, and larger jobs now have to be split into several batches to stay under the 200 MB input-file limit. So a fix on the file_id path would be very welcome rather than just a doc change.

Happy to supply more batch ids, request ids or full error files if that helps the investigation.

4

Hi and welcome to the community @Bommel !

I did also reproduce this with .txt files and to me it appears to be an issue with the Batch API referencing uploaded files more broadly.

5

seconding this issue on the Sora batch endpoint as well

6

You wanted to use previously uploaded images as reference for the video generation and then the API returned the 401 error message?

7

No, this was with a new batch video gen request with fresh image uploads

8

I cannot believe this is still not fixed! Do you not have other non-forum-browsing customers using this functionality, that are seeing the same issues? You have numerous reports on this; we’re a day later and still the same 401 errors when referencing file uploads.

9

If you have high blood pressure, you may want to consider blood pressure medication. I have to take it myself when I get impatient with impatient people.

10

I have plenty of patience, but the service I pay for is down - the status page is all green and there’s no official words on it being an issue, so everyones services are breaking - this also happened on the 16th this month, albeit it recovered on its own. It was down likely 15+ times during 2025 as well. I don’t think it’s unfair to air frustrations at the provider and push for a proper fix.

11

There are no paid OpenAI Dev employees on this forum. We are volunteers that spend time trying to help folks. @VeitB already asked the dev team to take a look. Nothing more can be done.

Your impatience does nothing to expedite the solution.

12

Hi everyone,

I was processing scanned book pages using the Batch API with gpt-image-2 and /v1/images/edits.

Initially, my Batch workflow was working perfectly. I successfully processed around 150 pages using uploaded image files and file_id.

Then, without making any changes to my script or JSONL structure, the Batch API suddenly started failing every request with:
Unable to authorize file access.
The individual Image Edit API continued to work correctly with the same images and API key, so the problem appeared to be specifically related to Batch API access to the uploaded image files.

I also:

  • Created a new API key
  • Confirmed the key was assigned to the correct project
  • Confirmed the source files existed
  • Confirmed the uploaded files had purpose: user_data
  • Tested the same image individually through /v1/images/edits
  • Confirmed that the individual API request worked successfully

However, Batch requests using:
"images": [
{
"file_id": "file-..."
}
]
continued returning:
{
"error": {
"message": "Unable to authorize file access.",
"type": "invalid_request_error"
}
}
Workaround that worked for me

Instead of passing the uploaded image using file_id, I changed the Batch request to use the image data encoded as Base64.

The workflow is now:
PDF page
↓
Render to PNG
↓
Read image bytes
↓
Base64 encode image
↓
Create JSONL Batch request
↓
/v1/images/edits
↓
gpt-image-2

The JSONL request contains the image directly rather than relying on Batch to authorize access to a separate uploaded image file.

For example, the working request structure is essentially:
{
"custom_id": "page-121",
"method": "POST",
"url": "/v1/images/edits",
"body": {
"model": "gpt-image-2",
"images": [
{
"...": "base64 image data"
}
],
"prompt": "...",
"quality": "medium",
"output_format": "jpeg",
"n": 1
}
}
I then submit the JSONL normally through the Batch API.

Result

This workaround is currently working for me.

I tested it with the same type of scanned pages that were previously returning:
Unable to authorize file access
The Batch completed successfully:
status: completed
completed: 1
failed: 0
total: 1

The generated image was successfully downloaded from the Batch output and the image quality was essentially the same as the successful individual Image Edit request.

So, at least for my workflow, the problem appears to be avoided by embedding the image data in the Batch request instead of referencing the uploaded image through file_id.

Has anyone else encountered the same Unable to authorize file access issue with /v1/images/edits in Batch API recently?

I’m particularly interested in knowing whether this is a temporary Batch file-access issue or whether there has been a recent change to how image files are authorized/referenced in Batch requests.

Current workaround: Base64 image data → JSONL → /v1/images/edits → Batch API.

This has allowed me to continue processing my remaining pages while avoiding the file authorization error.

13

Same issue here, also starting on 2026-08-19 — “Unable to authorize file access”
We’re seeing the exact same error in the Batch API, and it started on the same date (2026-08-19). Our workflow had been running fine for months with no code changes.
Setup:

  • We upload attachments via /v1/files with purpose=“user_data” (each upload returns a valid file_id, HTTP 200).
  • We then reference those file_id values inside each line of the batch JSONL (endpoint: [/v1/responses OR /v1/chat/completions — confirm which one you use]).
  • completion_window: “24h”.

What we observe:

  • Batches complete normally (status “completed”), but nearly every request that references an uploaded file_id fails.
  • The error file returns, per record: [] “Unable to authorize file access.” (no error code, just this message)
  • Example: a 500-record batch came back with ~500 failed / 0 completed.
  • The ONLY requests that succeed are the ones with NO file attachment — those run the prompt fine. Every request that references a file_id fails.

Things we ruled out on our side:

  • Not file expiration: batches finished within ~4–7h, well inside both the file
    lifetime and the 24h completion window.
  • Not a project/key mismatch: the file upload and the batch creation use the exact
    same API key (same project), and the upload itself returns 200 with a valid file_id.
  • No code or config changes on our end around that date.

This lines up with what others are reporting here. Did someone from OpenAI confirmed whether this is a known regression in how the Batch API resolves uploaded file_id references, and whether there’s an ETA for a fix?

Thanks!

14

thanks, I was able to resolve this by adding a toggle to be able to switch to the base64 version while this issue persists