Gemini API Error Inquiry

[mesea]

We are encountering the following message, and the Gemini API is not working:

We\\'re sorry...<\\\\/h1>

... but your computer or network may be sending automated queries. To protect our users, we can\\'t process your request right now.<\\\\/p>

Is there any way to resolve this issue?

[mesea]

We are resubmitting this inquiry with the error code included. (Error code: 417)

We are encountering the following message, and the Gemini API is not working:

We\\'re sorry...<\\\\/h1>

... but your computer or network may be sending automated queries. To protect our users, we can\\'t process your request right now.<\\\\/p>

Is there any way to resolve this issue?

[Philip_Niewold]

Same issue here, payloads that were fine before now suddenly generate 417 errors. These are regular payloads, so don’t know what happened in flagging behaviour.

[Philip_Niewold]

Investigated further:

Prompt doesn’t seem to matter (tried different ones, all give 417)
Origin doesn’t seem to matter (tried from different IP’s, all give 417)
API Key doesn’t seem to matter (tried different key belonging to different Google Dev account, always 417), the same API keys do work in AI Studio with the same prompt

So, seems a general Google related error

[One_Universe]

Hi I am getting the same error message for the past 4 hours. I am using the Gemini API for generating images with Nano Banana and everything was working fine for the past 3 months. I hope this is some bug/issue with the Google servers and not with my server IPs Every request now is blocked. I hope it will be resolved soon. Do you have any idea what I could do?

[Patrick_Groenendijk]

Did the same troubleshooting and testing same issues.

[Philip_Niewold]

It seems to be related to a tightening of the size restriction. I’m only getting it with an image upload (base64) added. When I resize the image and then base64 encode it, the error dissappears.

The speed of the 417 response indicates that it doesn’t actually reach the LLM, so the addition of a simple size filter should be the cause. Testing and confirming now.

[Philip_Niewold]

I have confirmed it (on different keys/IP’s etc.), if you reduce the size of the payload (in my case, the base64 encoded image), it doesn’t return a 417 anymore.

So the error content is misleading.

[One_Universe]

Yes, I’ve also tried that method. And if I use only one image with my prompt and the image size is below 500kb I don’t get the error. Unfortunately this is not a working workaround for me because I need the images to be in higher resolution. I hope this won’t be a permanent limitation.

[abd_kufa]

I encountered the same problem two hours ago and I’m still looking for a solution. maybe its a bug

[Dev_Elite]

I’m having the same issue, even with short text prompts.

[One_Universe]

I’ve found a workaround working with large size images. You just need to make the requests with direct URLs of the images with the prompt and not to add them as base64 prompt. Like that:
$parts = [
[
‘file_data’ => [
‘mime_type’ => ‘image/jpeg’,
‘file_uri’ => ‘https://yourdomain.com/image_1.jpg’,
],
],
[
‘file_data’ => [
‘mime_type’ => ‘image/png’,
‘file_uri’ => ‘https://yourdomain.com/image_2.png’,
],
],
[
‘text’ => $prompt,
],
];

$payload = [
‘contents’ => [
[
‘role’ => ‘user’,
‘parts’ => $parts,
],
],
‘generationConfig’ => [
‘responseModalities’ => [‘IMAGE’]
]
];

[mik]

I’m experiencing the same error as well. I’m not sure whether this is a temporary bug in Google Gemini or something more permanent. It was working normally just a few hours ago, and then suddenly it stopped working. As far as I can see, there haven’t been any updates that would explain the change.

[AitorWilzig]

Same error here. never had this problem before. must be a gemini’s bug

im not using images, just text

[SanterPD]

Hey everyone, just wanted to share what worked for us. We were getting the exact same 417 (Expectation Failed) error across all our C#/.NET integrations (Revit and Word add-ins) whenever we sent larger payloads like documents or images.

We isolated the issue by testing with a minimal Python script, which worked perfectly. It turns out the error is heavily tied to the Expect: 100-continue header, which C#’s HttpClient automatically attaches to requests with larger bodies. It seems Google’s proxy/firewall infrastructure recently added a strict size filter that aggressively rejects this specific pre-flight check, instantly returning the 417 error without even reaching the LLM.

The Fix for C#/.NET: You just need to explicitly disable this header in your code before making the request, forcing the client to send the payload directly:

C#

// If using modern HttpClient:
httpClient.DefaultRequestHeaders.ExpectContinue = false;

// If using older .NET Framework (like VSTO or Revit Add-ins):
System.Net.ServicePointManager.Expect100Continue = false;

Once we disabled that header, our large text requests and file uploads started working perfectly again. Hope this helps anyone stuck on the same stack!

[Gonzalo_Basaldua]

Thanks, it works!

For curl:

curl -H “Content-Type: application/json”
-H “Expect:” \

[One_Universe]

@SanterPD

Hey everyone, just wanted to share what worked for us. We were getting the exact same 417 (Expectation Failed) error across all our C#/.NET integrations (Revit and Word add-ins) whenever we sent larger payloads like documents or images.

We isolated the issue by testing with a minimal Python script, which worked perfectly. It turns out the error is heavily tied to the Expect: 100-continue header, which C#’s HttpClient automatically attaches to requests with larger bodies. It seems Google’s proxy/firewall infrastructure recently added a strict size filter that aggressively rejects this specific pre-flight check, instantly returning the 417 error without even reaching the LLM.

The Fix for C#/.NET: You just need to explicitly disable this header in your code before making the request, forcing the client to send the payload directly:

C#

// If using modern HttpClient:
httpClient.DefaultRequestHeaders.ExpectContinue = false;

// If using older .NET Framework (like VSTO or Revit Add-ins):
System.Net.ServicePointManager.Expect100Continue = false;

Once we disabled that header, our large text requests and file uploads started working perfectly again. Hope this helps anyone stuck on the same stack!

Thank you! I can confirm it works with large files and large text prompts.

[AitorWilzig]

it works. ur the best thank u