Batch API: code 7 "The caller does not have permission" on File API fileUri (works synchronously)

Gemini API
1

Since 2026-09-14 ~18:14 (UTC+8), every batchGenerateContent job in our project completes with
state: BATCH_STATE_SUCCEEDED but the inlined response contains
error: { code: 7, message: “The caller does not have permission” }.

The same API key, same model and the SAME uploaded file work correctly through synchronous calls.
Nothing changed on our side. Status page shows All Systems Operational.

ENVIRONMENT

  • Model: models/gemini-3.7-flash (version 3.7-flash-08-2026)
  • Endpoint: generativelanguage.googleapis.com/v1beta
  • Billing: paid tier, active, no spend cap
  • Key: authorization key, bound to a service account, restricted to “Gemini API”
  • Input: audio/mpeg, 30-70 MB, uploaded via resumable File API upload
  • Client: Google Apps Script (UrlFetchApp), x-goog-api-key header

WHAT WE SEND (one inlined request per batch)
{
“batch”: {
“display_name”: “tx_REDACTED_1.mp3_1789470464367”,
“input_config”: { “requests”: { “requests”: [{
“request”: { “contents”: [{ “parts”: [
{ “file_data”: { “file_uri”: “…/v1beta/files/759tqz2aernv”, “mime_type”: “audio/mpeg” } },
{ “text”: “” } ] }] },
“metadata”: { “key”: “transcript” } }] } }
}
}

ACTUAL RESULT (GET /v1beta/batches/y2a8z10m37opym1din090edczvjbtd8xm6j7)
{
“metadata”: {
“model”: “models/gemini-3.7-flash”,
“output”: { “inlinedResponses”: { “inlinedResponses”: [
{ “error”: { “code”: 7, “message”: “The caller does not have permission” },
“metadata”: { “key”: “transcript” } } ] } },
“createTime”: “2026-09-15T12:02:41Z”,
“endTime”: “2026-09-15T12:22:32Z”,
“batchStats”: { “requestCount”: “1”, “failedRequestCount”: “1” },
“state”: “BATCH_STATE_SUCCEEDED”
},
“done”: true,
“response”: { “inlinedResponses”: { “inlinedResponses”: [
{ “error”: { “code”: 7, “message”: “The caller does not have permission” },
“metadata”: { “key”: “transcript” } } ] } }
}

The JOB succeeds; only the inner request is denied. There is no top-level “error”,
no blockReason, no finishReason and no token counts anywhere in the payload.

THE SAME KEY AND THE SAME FILE WORK SYNCHRONOUSLY
All three made with the same key, minutes after the batch above failed:

  1. GET /v1beta/files/759tqz2aernv → 200
    { “mimeType”: “audio/mpeg”, “sizeBytes”: “44972534”, “state”: “ACTIVE”, “source”: “UPLOADED” }

  2. POST /v1beta/models/gemini-3.7-flash:countTokens with the same file_uri → 200
    { “totalTokens”: 59960, “promptTokensDetails”: [{ “modality”: “AUDIO”, “tokenCount”: 59960 }] }

  3. POST /v1beta/models/gemini-3.7-flash:generateContent (text only) → 200, serviceTier: standard

So the file exists, is ACTIVE, is readable by this key, and the model can ingest it –
but batch execution reports that “the caller” has no permission to it.

A SECOND, NEWLY CREATED KEY REPRODUCES IT IDENTICALLY
We created a new authorization key in the same project (bound to a DIFFERENT service account,
same “Gemini API” restriction) and swapped it in. Same row, same audio, three separate uploads:

submitted 14:06 (+8) | key A | files/aq0mtg77ziaf | code 7
submitted 19:07 (+8) | key A | files/3tctp2anqopf | code 7 after 4m44s
submitted 20:02 (+8) | key B | files/759tqz2aernv | code 7 after 19m51s

Time-to-failure varies 4-46 min across our jobs, which we read as queue latency, not signal.

TIMELINE

  • Worked normally 2026-09-02 through 2026-09-14 18:14 (+8): 473 successful transcriptions.
  • From the first job on 2026-09-15: 100% of batches fail this way. 0 successes.
  • No deployment, code, key or configuration change in that window (verified by SHA of our
    Apps Script projects: unchanged since 2026-09-08 and 2026-09-12).

RULED OUT
Application state; stale vs fresh file URIs; file deletion; File API storage quota (6 files,
far below 20 GiB); key type; key identity (second new auth key, different service account);
key restrictions; project IAM; billing tier and spend cap; model availability; our code.

QUESTIONS

  1. Under what identity does a batch job read a File API resource referenced by
    file_data.file_uri?
  2. Did that authorization path change on or around 2026-09-14?
  3. Is there a project- or key-level setting required for batch jobs to access File API
    resources that is NOT required for synchronous calls?
  4. Is referencing File API files from inlined batch requests still supported? The Batch API
    guide states that with multimodal input you “can reference other uploaded files”.

Happy to provide project ID and full unredacted payloads privately.

2

Getting the same error

3

Confirming this, with evidence that the problem is broader than File API references.

We hit the same failure window: our last successful batch was 2026-09-14 16:16 UTC, our first
failure 2026-09-15 07:48 UTC. Since then the Batch API has been effectively unusable for us.

The key finding: a text-only request fails too.

I ran a controlled 2-line batch — one request with a fileData reference to an ACTIVE Files API
object, one request with plain text and no file reference at all. Same batch, same model
(gemini-2.5-flash), so identical queue conditions. Both failed:

with-file  => error code 13, "Internal error encountered."
text-only  => error code 13, "Internal error encountered."

Since the text-only request carries no file reference, fileData cannot be the root cause. That
seems worth knowing before anyone spends more time on the Files API angle.

We also see different error codes than reported here. Across our jobs:

  • 33 requests (with fileData) → code 5, "Requested entity was not found." — 100% of lines
  • the 2-line probe above → code 13, "Internal error encountered." — both lines
  • this thread reports code 7, "The caller does not have permission"

Same shape in every case: the batch reaches BATCH_STATE_SUCCEEDED, and the inner requests
carry the error.

The files themselves are fine. We verified all 99 referenced frame files were ACTIVE and
unexpired, and a live generateContent call using the exact same fileUri returned a correct
answer. So the same key, same file, same model works synchronously and fails in batch — matching
the original report.

There is also a separate hang behaviour. Several batches were created and then simply never
picked up — updateTime stayed identical to createTime for hours:

  • a 1-request batch: BATCH_STATE_RUNNING for 7h24m, never returned
  • a 23-request batch: 6h, never returned
  • the 2-line probe above: took 4h28m to complete and then returned the code 13 errors

For comparison, before 09-14 our batches typically completed in 4–10 minutes.

It is intermittent, not total. One single-request batch (no file reference) completed
successfully on 09-15 while everything around it hung or errored.

Batch job names, if useful for lookup:

batches/qdurd7wtanp4ko6c8l7mpgndvd0c7491hd7g   33 reqs, all code 5
batches/wlvywn7ai5k3f0a7mrj6u4ndtpiotfrpch1n   2-line probe, both code 13
batches/u7k7ad12mp3dz9eb358xiusgm62r4qeueo38   1 req, RUNNING 7h24m, never returned

Models involved: gemini-2.5-flash and gemini-3.1-flash-lite. The status page has shown
“All Systems Operational” throughout.

Is there any acknowledgement or ETA on this? We have had to move our whole pipeline to synchronous
calls as a workaround, which costs roughly 2x — sustainable briefly, not indefinitely.

4

Hello,

To help us trace the background job executions, could you share your Project ID and recent Batch IDs via direct message?

To send a direct message, click on my profile picture or name, and then select the Message button.

5

Hi all letting you know that this should be fixed now.