429 RESOURCE_EXHAUSTED at 0.03% of quota — reproducible across projects, tiers and endpoints

Gemini API
21

Just a note on the performance concern with the Base64 workaround: it depends on where you do the conversion.

In our setup the file is converted to Base64 in the user’s browser, before it ever reaches our backend, so there’s no server-side download-and-re-upload cycle. No extra server traffic, no memory overhead — the cost sits with the client that just picked the file anyway.

We migrated a production receipt-OCR pipeline from fileData.fileUri to inline Base64 across ~34 test documents (JPEG, PNG, PDF). Two side effects worth mentioning: median processing time dropped by roughly half, since Google no longer has to fetch the file from our CDN, and PDF input started working.

For anyone hitting this from a browser-based app, client-side conversion may be a better answer than waiting for the ingestion path to be fixed. It’s a different architecture rather than a workaround.

22

any update ? have this uri issue being solved ?

23

Is there any update from the team on this issue?
The problem is still fully reproducible with fileData.fileUri, including with the public PDF test case shared above, and multiple users have now confirmed the same behavior.
Client-side Base64 conversion may be a workaround in some applications, but in our production architecture the Gemini API key and API calls are intentionally kept server-side for security reasons, in line with Google’s recommendation not to expose API keys in client-side code.
Thank you.

24

Additional update: I also tested the Interactions API, to rule out an issue specific to generateContent.

I used:

  • gemini-3.5-flash-lite
  • gemini-3.6-flash
  • gemini-3.7-flash
  • POST https://generativelanguage.googleapis.com/v1beta/interactions
  • The same public PDF URL currently shown in Google’s External HTTP URL documentation:
    https://ontheline.trincoll.edu/images/bookdown/sample-local-pdf.pdf

All three models return HTTP 429:

{

“error”: {

"message": "Resource has been exhausted (e.g. check quota).",

"code": "too_many_requests"

}

}

In particular, gemini-3.6-flash + Interactions API + this PDF URL is effectively the same setup as the current External HTTP URL example in the Gemini API documentation.

Therefore, this does not appear to be specific to generateContent or to a particular Gemini 3.x model. It appears more likely to be related to the shared external URL ingestion/fetch path.

The response also still contains no description explaining the specific cause of the 429.

25

Hey Guys,
It does not work with Google AI Studio API Keys!

It only works via Google Agent Platform.
on genai sdk use enterprise=True with service account key or ADC (Application Default Credentials) for authentication as per projects settings

26

Sorry about this everyone - this is now fixed.

27

I just tested it out again. I now no longer get HTTP 429 RESOURCE_EXHAUSTED with “URL_REJECTED-REJECTED_CLIENT_CAPABILITY” in the Google AI Studio logs when adding an external image URL to an API request (specifically an AWS S3 URL).

I now get HTTP 403 PERMISSION_DENIED with “URL_REJECTED-REJECTED_CLIENT_CAPABILITY” in the Google AI Studio logs when adding an external image URL to an API request.

The error has slightly changed, but it’s still there.

28

this also happend on Antigravity, Mine is on version 1.23.2 but other also experiencing this on version 2.+, is there any update why this is happend or is it fixed?

thank you

29

http 403 , what r u guys up on ?

30

Update: the issue is still reproducible, but the error has now changed from 429 to 403.

I tested again using a minimal standalone PHP script, completely separate from my production application.

Test conditions:

Model: gemini-3.6-flash
Endpoint: https://generativelanguage.googleapis.com/v1beta/interactions
Public PDF URL:

<http/ontheline.trincoll.edu/images/bookdown/sample-local-pdfpdf>

Authentication: API key via x-goog-api-key
The file is passed directly as an external URL. No Base64 conversion or server-side file download is performed.

The request now returns HTTP 403:

{
“error”: {
“message”: “The caller does not have permission”,
“code”: “permission_denied”
}
}

Text-only requests using the same API key/project still work normally. The failure occurs when an external file URL is included.

Previously, the same external-file path returned:

429 RESOURCE_EXHAUSTED

After the reported fix, it now returns:

403 PERMISSION_DENIED
The caller does not have permission

Therefore, from my environment, the external URL ingestion issue does not appear to be resolved; the returned error has changed from 429 to 403.

This is also reproducible with the public PDF URL used for our minimal testing, so it is not specific to Yahoo-hosted images or to my production application.

Could you please confirm whether external HTTP URL input with Gemini API keys is currently expected to work with gemini-3.6-flash and the Interactions API?