Batch API rejects every valid purpose="batch" file — “organization does not have access to it”
Org: [org-id] Started: between 2026-08-27 and 2026-09-01. Batches created on 2026-08-27 completed normally. Now: 100% of batch creations fail during validation, on every endpoint.
Every batch we create fails within ~30 seconds with:
code: invalid_request
param: file_id
line: null
msg: Cannot find file file-XXXX, or organization org-xxcTbBzvrXqhEA2YWGVznp1i
does not have access to it.
request_counts stays at 0 completed, 0 failed of 0 total, so validation fails before any
request in the file is read.
The file is present and readable
For the same file id the batch says it cannot access:
files.retrieve(file_id) returns status: "processed" with the correct byte count
files.content(file_id)downloads the full file successfully (10,426 chars, verified)
the dashboard shows the file linked in the batch detail page under Files → Input, and the
link opens
So the file exists, belongs to this org, and is readable through the Files API by the same key
that created the batch. Only the batch validator cannot see it.
What we ruled out
Hypothesis
Test
Result
API key permissions
created a second, unrestricted key
identical error, same org
Endpoint-specific
/v1/responsesand/v1/chat/completions
identical error on both
File propagation delay
waited for status: "processed", then retried repeatedly
identical error
Something about this file
reused an older file that had worked previously
identical error
File expiry / retention
uploaded with explicit expires_after (30 days)
identical error
Malformed JSONL
1-line minimal file, {"custom_id","method","url","body"} only
identical error
Model availability
same request body sent synchronously
works normally
The last point matters: the exact same request body that fails inside a batch succeeds
immediately through the synchronous API. Nothing is wrong with the payload, the model, or the key.
Timeline on this org
Date
Result
2026-08-27 17:50–18:00 UTC
batches completed normally on /v1/chat/completions, /v1/embeddings, /v1/responses, /v1/images/generations
2026-09-01 18:56 UTC onward
every batch fails, all endpoints
Failed batch ids
batch_6a972425f74881909af71c93b6eb1bf0 /v1/responses 2026-09-01 19:14 UTC
batch_6a972405fd7081909bebbdc24251d942 /v1/responses 2026-09-01 19:14 UTC
batch_6a97233c86a08190a83621d5f72e8cd6 /v1/responses 2026-09-01 19:10 UTC
batch_6a9721e6a0ec8190a8a85c8fa569e0f9 /v1/chat/completions 2026-09-01 19:05 UTC
batch_6a9721a8ef748190b6820ca1d5010823 /v1/chat/completions 2026-09-01 19:04 UTC
batch_6a972133f7bc8190ad6acebccd5106e5 /v1/responses 2026-09-01 19:02 UTC
A working reference, for comparison:
batch_6a9079ca9e9c819080b8cbad5d3718c2 /v1/responses 2026-08-27 17:54 UTC completed
@siddhant We’re experiencing the same project-level Batch file-validation issue with /v1/embeddings.
Our input files upload with purpose=batch, report status=processed, and are retrievable—including their contents—with the same project-scoped key. Batch validation nevertheless fails with “Cannot find file … or organization … does not have access,” with request_counts.total=0.
It also reproduces when creating the Batch through the OpenAI web UI with the affected project selected.
Hi Siddhant, our organization is also affected by the batch input file issue since 28 Aug.
Organization: org-hjg9vNP32nDt5tLLn0c9pzwh
Every batch fails validation with «Cannot find file …, or organization … does not have access to it», while the same file is processed and readable via the Files API. Reproduced with /v1/chat/completions and /v1/embeddings, with files uploaded both via /v1/files and the Uploads API. Latest failed batch: batch_6a9731bed3848190ba7d1a4500d0e7d0, submitted 2026-09-01 ~20:10 UTC.
Just to confirm, I tested again now that issues with API have gone green and I can still confirm and issue on our org org-agOkAOzSxFnJX6RhU5Yhct4O
batch_6a9735ee7f748190b5b165d73b73d7f1 / file-8NiQjrNBb8gBF8d1zWWb4o, created 2026-09-01 20:30:39 UTC (22:30 CEST), failed with the same Cannot find file … or organization org-agOkAOzSxFnJX6RhU5Yhct4O does not have access to it, request_counts.total: 0.
@siddhant Could you please apply the mitigation to our organization as well?
Org ID: [org-id]
Since 2026-08-29 every single POST /v1/batches is rejected during validation — four days now, 100% of our batches, on both /v1/responses and /v1/chat/completions:
invalid_request (param: file_id) — “Cannot find file file-…, or organization [org-id] does not have access to it.”
The input file is uploaded with purpose=batch and GET /v1/files/{id} returns status: processed both at the moment the batch is created and hours later. Re-creating the batch from the same input_file_id once an hour for five hours never helps.
Minimal repro from a few minutes ago — a 167-byte single-line JSONL, uploaded and verified as processed; the file is still on the account if you want to inspect it:
file-AqCSsoZfY19QWv9LtYjteT (uploaded 2026-09-01 21:17:39 UTC)
batch_6a9740f4e0048190b1f5cfe10eec1e9e (/v1/chat/completions) → failed with the error above
Recent production batches, all failed the same way (2026-09-01 UTC):
batch_6a9714de66848190b004a418f1dde846 (file-FPhgizvyc6v1bLQvGhufWp)
batch_6a9714ddd420819099a170dfd6138978 (file-FGZvDKbBxvgbM7FQ5d9Fhd)
batch_6a9714dd5d8c8190ba4133f3834ca090 (file-GQSCCEeyaph12TThwVY9MM)
batch_6a9714dce72c8190b4664d3b57c085e7 (file-FaFotiXJVFbaxnjbP6t9ro)
batch_6a9714db8718819086c2e4a99548e2e5 (file-ABaBaBMHT8K3kQmpxRiXF6)
Affected: /v1/images/generations and /v1/responses (both fail identically).
Every batch fails validation ~60s after creation with:
“Cannot find file <file_id>, or organization
[org-id] does not have access to it.”
Last successful batch: batch_6a90987f8064819089805b64828c2871 (2026-08-27 20:05 UTC)
First failure: batch_6a91e8d31dc8819090aa76551a9affdf (2026-08-28 20:00 UTC)
Nothing changed on our side between those two — same API key, same project,
same code path, same JSONL generator.
Recent failed batch ids:
batch_6a972fffb9f0819098688a32ca0eaf61 2026-09-01 20:05 UTC /v1/images/generations
batch_6a972ed3701c81909d4934ea03a83107 2026-09-01 20:00 UTC /v1/images/generations
batch_6a95de8008d081908ce472904266c2ec 2026-08-31 20:05 UTC /v1/images/generations
batch_6a95dd56967c819091b7dac797fd1ae9 2026-08-31 20:00 UTC /v1/images/generations
batch_6a973a66b1488190ad5bcc87db49b04d 2026-09-01 20:49 UTC /v1/responses (text canary)
batch_6a9742f26d6481909e1f2095518c5c65 2026-09-01 21:26 UTC /v1/responses (text canary)
One extra data point that may help isolate this: I resubmitted the exact input
file from the last batch that COMPLETED on Aug 27 — file-T8Q2DokDqWRXtNuLYkdRNw,
unmodified, still status:“processed” and still retrievable via the Files API with
the same key. It now fails validation with the same “Cannot find file” error
(batch_6a973ce0bf0081909e140104a907aa6f). So this is not about how files are being
uploaded — the batch validator can no longer resolve files it resolved fine before.
Also ruled out on our side:
Not model/endpoint specific: a 1-line text /v1/responses batch fails the same way.
Not file visibility: GET /v1/files/{id} returns status “processed” with the same key.
Not general async file resolution for this org: attaching a file to a vector store
with the same key ingests successfully (status “completed”).
The solution that worked for me was to retain two API keys, one legacy for all created before this issue, then a new one for the new mitigation project, and have a switcher determine which one to use depending on date something is created, then also tagging new results with legacy and current project labels
@siddhant I’m facing the same problem, can you help me please?
Organization:org-gehz4yaYvLGHsGjEjXGqGvt6 First observed: 2026-09-02 00:57 KST (UTC+9) Still failing: at least until 05:57 KST — 5+ hours
I am seeing the same Batch API file-visibility failure described in this thread.
Every batch fails about 60 seconds after creation with:
Cannot find file file-XXXX, or organization org-gehz4yaYvLGHsGjEjXGqGvt6 does not have access to it.
However, client.files.retrieve(file_id) returns status="processed" for the exact same file both before batch creation and after the batch has failed.
A few things I tested:
I explicitly wait until files.retrieve().status == "processed" before calling batches.create(). One diagnostic file became processed in ~0.9 s, but the batch still failed.
The file remains present and processed after failure.
Multiple different files show the same behavior, including two ~1.5 MB / 100-request JSONL files and a 1-line diagnostic file.
Reusing the same already-processed diagnostic file at approximately t+5 min and t+20 min also failed identically.
request_counts.total = 0 and token usage remains 0, so the failure appears to occur before request execution.
Some example file IDs:
file-F6ppQDRek4ADvCSMk319PE — batch failed +61 s
file-N4KovvryZXRanHuNRsAYPL — batch failed +60 s
file-N5Luf5ZefLRs2LiL2deHRF — batch failed at 05:57 KST
I also tested a minimal 1-line batch using a deliberately nonexistent model. In this affected org, the batch still fails first with the file-access error, suggesting validation never reaches the request body.
Could org-gehz4yaYvLGHsGjEjXGqGvt6 please be added to the affected organizations being investigated/repaired?
Happy to provide batch IDs, additional file IDs, timestamps, or full API responses if useful.
Every batch since Sep 1 (JST) fails at validation with Cannot find file <file_id>, or organization org-GaX5AFICwTr11lHroTh3okAy does not have access to it. — including a minimal 1-request probe: batch_6a97559efbb88190b1c18de543bd9db6 (endpoint /v1/chat/completions, input file-3p9Nmey5DkGP3UTg7Gj9fL).
The input file is uploaded with purpose="batch", files.retrieve returns status processed before and after the failure, and the file is visible in the dashboard.
files.create and batches.create use the identical credentials — response headers on both calls show the same openai-organization and openai-project.
Batches in the same project completed normally on Jul 14–15. Non-batch chat completions still work fine.
Already reported via help.openai.com and escalated to a support specialist, but posting here as well since fixes seem to be applied per-organization from this thread. Thank you!
@siddhant — same issue here, please apply the mitigation to our org.
Org: org-DeNOc6hDPCW7CNzfoQlWAcni
Every batches.create fails validation since 2026-09-01 with
"Cannot find file <file-id>, or organization org-DeNOc6hDPCW7CNzfoQlWAcni does not
have access to it", while files.retrieve on the same ids returns status=processed
with correct bytes and purpose=batch. Sync endpoints, file uploads, and billing all
work; 68 batches completed historically (images batches fine as late as 2026-08-24).
Failed probe batches (minimal 1-request inputs unless noted):
- batch_6a975c1e805081908d92b9e4dcb575b1 — /v1/chat/completions, fresh file (2026-09-01)
- batch_6a975ca9bdf8819084a993c5ef835141 — references a 2026-08-24 input file that
previously fed a COMPLETED batch, so the validator cannot see OLD files either
- batch_6a975ce3cce88190a901e8577447fda0 — raw REST, minimal headers (no SDK)
- batch_6a9751348c80819093079a39b3e16e98 — /v1/images/generations production batch
(our main workload, 382 requests)
- Also reproduced identically from a brand-new project + fresh sk-proj key.
Thank you!
Hi, it would be great if it can be fixed for my org.
Example failed batch: batch_6a97606290608190ad567c456229b189
Batch submitted: 2026-09-01 23:31:46 UTC.
Org: org-rufv3hm0NXfKBxD2S82zfpmF
Failing since: Aug 19, 2026 (every batch, any endpoint)
Error: "Cannot find file ..., or organization ... does not have access to it"
Files upload fine (purpose=batch, status=processed, readable via files.retrieve)
Recent failed batch IDs:
batch_6a976745453c8190af23e17b47ca21fc (Sep 1, original key)
batch_6a976b5075a08190985f343aad04cc62 (Sep 1, brand-new project + new key — same error)
batch_6a930a0b2b588190b664a207f517429e (Aug 29)
Minimal repro: 1-line JSONL to /v1/chat/completions fails the same way.
