AQ. key: generateContent works but Files API upload returns 403 PERMISSION_DENIED

Gemini API
,
1

Same API key, same project: ListModels and generateContent both
succeed, but the Files API upload endpoint returns 403. I have not been
able to find any role or setting that changes this, and I suspect the
key type is the relevant variable.

Environment

  • Project: sbt-invoices-o..
  • API: Generative Language API, enabled
  • Model: models/gemini-3.6-flash
  • Billing: active, project incurring charges since 2026-08-13

Credential

API key with the AQ. prefix — Authentication Key bound to service
account n8n-gemini@sb..invoices-ocr.iam.gserviceaccount.com.

Restricted to generativelanguage.googleapis.com, as required by the
June 19, 2026 unrestricted-key policy. No IP or referrer restrictions.

Works

GET v1beta/models → 200, full model list
POST v1beta/models/gemini-3.6-flash:generateContent
{“contents”:[{“parts”:[{“text”:“ping”}]}]}
→ 200, normal completion

Fails

POST https://generativelanguage.googleapis.com/upload/v1beta/files

HTTP 403
{
“error”: {
“code”: 403,
“message”: “The caller does not have permission”,
“status”: “PERMISSION_DENIED”
}

Ruled out

  • Invalid key — ListModels works
  • IP / referrer restriction — none configured
  • API not enabled — error is PERMISSION_DENIED, not
    SERVICE_DISABLED, and generateContent on the same API works
  • Billing — linked, project billed since 2026-08-13
  • Model-specific — identical on gemini-flash-latest, 3.5, 3.7
  • IAM role — service account granted Service Usage Consumer, then
    escalated to Editor on the project. The 403 is unchanged.

That last point is why I am posting. Editor covers effectively every
project-scoped permission. If the 403 survives Editor, then either the
required permission is not project-scoped, or this credential type is
not authorized for this endpoint at all.

Questions

  1. Is the Files API supported for AQ. Authentication Keys bound to a
    service account? If not, please say so explicitly.
  2. If it is supported, which permission governs upload, and which role
    contains it? Editor does not appear to.
  3. Is OAuth2 (Authorization: Bearer, service account token) the
    intended mechanism for the Files API instead of an API key? If so,
    which scope?

Why this might be worth localising

Most reports in this category see everything fail at once, so the
boundary is invisible. Here it is clean: one key, one project, one
endpoint works and another does not.

The September 2026 deprecation of standard keys moves everyone onto the
AQ. type. If the Files API does not accept AQ. keys, that is worth
documenting before the migration rather than after.

(Workaround in place: sending the PDF as inline_data instead of via
the Files API. Works fine, but caps requests at 20 MB.)
}

2

Hello @sbt-solution ,

This issue is most likely not due to the AQ. key format. We are unable to reproduce this issue at our end, can you please share a CURL?