Short answer
If the Gemini image API returns HTTP 200 but the response has nocandidates and only promptFeedback.blockReason (most often OTHER), the request was blocked by the provider’s input check before generation started.
- This kind of block usually comes back within a few seconds, much faster than a normal image
OTHERdoes not state a reason, andsafetyRatingsis often empty- It is not necessarily related to how the prompt is written; often a single reference image triggers it
- gemini-3-pro-image (Nano Banana Pro) checks input more strictly than gemini-3.1-flash-image, so the same request may be blocked on Pro and succeed on flash
How to recognize it
A typical response looks like this:A tested case
In September 2026 (UTC+8) we re-ran a fashion-catalog request: one prompt plus 6 reference images (pose, person, scene, outfit, a shoes-and-socks collage, and a hat), 2:3, 2K,responseModalities: ["IMAGE"].
- gemini-3-pro-image returned
blockReason: OTHER3 times in a row; the same request succeeded on gemini-3.1-flash-image - By repeatedly splitting the images in half, we found that the only trigger was the person reference image: an AI-generated character sheet with front, back, side, and close-up face panels
- That image was blocked with any prompt, including an unrelated instruction such as “change the background to light gray”
- The two images we suspected most, a real-person pose photo with a watermark and a hat photo with a logo, both passed on their own
In other words, this check can be very sensitive to the exact pixels of certain images, and re-exporting the image once lets the request through. The provider does not publish what
OTHER is based on, so we cannot attribute it further.
This case shows that sending many reference images in one request, or merging several steps into a single generation, is not the problem in itself. When you see
OTHER, find the image first before rewriting the prompt or splitting the workflow.How to find the image
1
Step 1: Confirm that it reproduces
Resend the request unchanged 2–3 times. A
blockReason block usually reproduces consistently. If it only fails sometimes, the problem is more likely the NO_IMAGE kind.2
Step 2: Rule out the prompt
Keep all images and replace the prompt with a simple, unrelated instruction, such as “change the background to light gray.” If it is still blocked, the cause is in the images.
3
Step 3: Split the images in half
Send each half separately, then keep splitting only the half that is still blocked until you reach a single image. Six images take at most three rounds.
4
Step 4: Fix that image
Re-export the image as described under “Recommendations” below, then send the full request again to confirm.
Recommendations
Scenario 1: Manual work (generating in a canvas or tool)
- Re-export reference images before uploading them: use any image editor (such as the built-in Preview app or Photoshop) to export JPEG at quality 90–95, with the long edge at 2048px or less.
- Downscale large images: originals with a long edge of 3000–4000px can be reduced to 2048px without affecting the result, and they upload faster.
- If a request fails within seconds, suspect a reference image first: re-export the image you added most recently and try again. If that does not help, check the images one by one as described above.
- Prefer full-body images as person references: in the case above, the front full-body panel passed on its own once the character sheet was split. If a character sheet keeps getting blocked, try using only its full-body view.
- Temporary alternative: if an image cannot pass on Pro, use gemini-3.1-flash-image for that step.
Scenario 2: Code (automated processing)
1. Preprocess every reference image before sending, instead of handling individual images: convert to sRGB → apply the EXIF orientation → limit the long edge to 2048px → re-encode as JPEG (quality 90–95) → drop metadata. The main benefit is a much smaller request body and faster uploads (the original request in the case above was about 4.6 MB). It also reducesOTHER blocks of this kind. Node.js example:
3. Log troubleshooting details: on every failure, record the
responseId and each reference image’s hash and dimensions. This lets you find the image quickly and gives us what we need if you contact support.
Frequently asked questions
Why does flash generate the image while Pro blocks it?
Why does flash generate the image while Pro blocks it?
The two models use different input checks, and Pro is stricter. A reference image that passes on flash and is blocked on Pro is expected behavior and does not mean the request itself is wrong.
Can AI-generated reference images be blocked too?
Can AI-generated reference images be blocked too?
Yes. The blocked image in the case above was a character sheet regenerated from the customer’s own photos. Whether an image is blocked does not map simply to where it came from; find and preprocess it as described on this page.
Are 6 reference images in one request too many?
Are 6 reference images in one request too many?
In the case above, 6 images were not the problem: after replacing the one person image, the full 6-image request generated normally.
Will a blocked request be charged?
Will a blocked request be charged?
Check the APIYI call logs to confirm whether the request created a charge record.
Still stuck? Contact support
Please include the following so we can help:- Model name and token group;
- The complete response (at least
promptFeedbackandresponseId) and therequest ID; - Time of occurrence (with time zone);
- The reference image you identified, if you can share it.
WeCom Support

Email Support
Support: [email protected]We recommend including “blockReason” and the model name in the subject.
Related documentation
Why Does the Gemini Image API Return NO_IMAGE?
Missing images caused by unclear prompt intent, and how to fix them
Nano Banana image generation failures
Common causes including safety, watermark removal, well-known IP, and minors
Gemini Image API Error Handling
The full response-checking order and user-friendly error messages
How do I read billing amounts in the logs?
Use call logs to confirm whether a request succeeded and was charged