Nano Banana API Not Working? Fix 429, 503, No Image, and Request Denied

When the Nano Banana API fails, classify the failure branch before you retry, change payloads, switch models, or change providers. A 429 RESOURCE_EXHAUSTED response points to quota or rate-limit pressure; 503 UNAVAILABLE usually starts as a capacity branch; 504 DEADLINE_EXCEEDED is a timeout branch; a text-only response needs response-part inspection; and request-denied wording needs a permission, safety, key, file-resource, or gateway split.

Start with the router below:

Keep the diagnostic signal clean: retest with the same model, endpoint, project, key, payload, input asset, and request format before you change more than one variable. If the branch changes during that retest, leave the old fix path and follow the new branch.

Evidence note: Google Gemini API troubleshooting, image-generation, rate-limit, and Files API references were checked on April 19, 2026, so stale quota tables, incident-rate percentages, and off-peak-window claims stay out of the recovery path.

429 RESOURCE_EXHAUSTED means quota pressure first

A real 429 RESOURCE_EXHAUSTED is the quota branch before it is an authentication branch, a model-quality branch, or a provider-switch decision. Google’s Gemini API troubleshooting reference maps RESOURCE_EXHAUSTED to rate-limit pressure, and the rate-limit reference makes the important operational point: limits are enforced at the project level, not just by whichever API key happens to make the request.

The first check is live quota state for the exact project and model. Do not rotate keys before that check, because two keys under the same project can hit the same ceiling. Also avoid copying old quota tables into production logic. Image-model limits, paid-tier state, and preview-model capacity can change, so the only reliable value is the current limit shown for the project you are using.

The safe next move is bounded backoff with jitter. A retry loop should slow down quickly, stop after a small number of attempts, and preserve the original error in logs. Non-urgent jobs should move to batch or queue processing instead of competing with live user requests. If every normal session hits 429, the problem is no longer a retry problem; it is a capacity-planning problem.

ts
const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

async function retryQuotaBranch<T>(run: () => Promise<T>, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      const message = String(error);
      if (!message.includes("429") && !message.includes("RESOURCE_EXHAUSTED")) {
        throw error;
      }
      const delay = Math.min(60_000, 1000 * 2 ** attempt) + Math.random() * 750;
      await sleep(delay);
    }
  }
  throw new Error("Quota branch still active after bounded backoff");
}

For a deeper quota workflow, use the exact 429 handoff: Fix Gemini Image 429 rate limits. If the issue is broad throughput rather than one burst, the Gemini API rate limits guide is the better route.

503 and 504 need separate recovery paths

A real 503 UNAVAILABLE is a temporary availability or overload branch. It does not prove that the API key is wrong, that billing will fix the request, or that the prompt is invalid. The first action is to keep the same request path and retry once with a bounded delay. Same model, same endpoint, same project, same payload. If the same request returns 503 again, the branch is still capacity. If it turns into 429, move to quota. If it turns into a structured client error, stop treating it as overload.

504 DEADLINE_EXCEEDED is different. Google’s troubleshooting guidance treats deadline exceeded as a timeout branch, often improved by increasing the client timeout or reducing request complexity. If the request is very large, includes a heavy input asset, or asks for a complex output, the fix may be load reduction rather than repeated retry.

The clean production pattern is:

1. Confirm the exact status code and status string.
2. Retry the same request path once or twice with exponential backoff.
3. For 504, raise the client timeout only if the service actually accepted the request and the client budget is too short.
4. For persistent 503, pause live retries, queue the job, or move to the exact 503 recovery workflow.

Deep 503/504 recovery belongs in Fix Gemini 3 Pro Image 503 overloaded errors. Use that route when repeated same-path tests keep proving capacity or timeout rather than quota, parsing, or permission.

No image or text-only output is a response-shape problem

No image does not always mean the model failed. The request can return a successful response and still fail the application because the code never finds an image part. Google’s image-generation documentation shows image output inside response parts as image data. That means application code has to inspect the parts instead of assuming the first returned part is a usable image.

Start with the response object:

ts
function extractInlineImage(response: any) {
  for (const candidate of response?.candidates ?? []) {
    for (const part of candidate?.content?.parts ?? []) {
      const data = part?.inlineData?.data;
      const mimeType = part?.inlineData?.mimeType;
      if (data && mimeType?.startsWith("image/")) {
        return { data, mimeType };
      }
    }
  }
  return null;
}

If that returns null, check four things before declaring an outage.

First, confirm the request asked for image output on the API surface you are using. Some surfaces require image response modalities or an equivalent output setting. Second, inspect finishReason. A safety finish is not the same as a network outage, and retrying the same prompt may keep returning no usable image. Third, inspect file and media references. A local path that worked in a notebook is not automatically a valid file resource for the API. Fourth, keep text-only output separate from denied output. Text-only can be a parsing or modality issue; denied output can be permission, safety, or gateway policy.

The repair is usually small once the branch is clear: request image output explicitly, loop through all response parts, save only real image parts, and fix file references so the API can access the input asset.

Request denied is a split, not a diagnosis

Request-denied wording is only an umbrella symptom. The real owner can be HTTP permission, key state, project configuration, safety policy, file access, or an upstream gateway. Treating every denial as the same problem is how teams waste time rotating keys, rewriting prompts, and changing endpoints in one noisy session.

Start with the response layer. If the status is 403 PERMISSION_DENIED, Google’s troubleshooting reference points to permission or authorization. Check that the API key is valid, the project has the Gemini API enabled, the key has not been blocked or exposed, and the request is going through the expected project.

Then check the model and prompt layer. A response with finishReason: SAFETY is a safety branch, not necessarily a 403 branch. Safety stops should be handled by revising the prompt or route, not by changing every credential. Keep the audit trail clear by logging the finish reason separately from the HTTP status.

Then check file and media ownership. The Files API reference treats uploaded files as API resources with names, URIs, MIME types, states, and ownership. A copied local filesystem path, stale file URI, or file owned by a different project can look like a denial from the application’s perspective even when the key itself is fine.

Finally, separate official API denial from gateway denial. If a proxy or compatibility layer adds its own policy, authentication, or route controls, capture the raw upstream status and the gateway status separately. The recovery owner is different when Google returns 403 than when a gateway rejects the request before it reaches Google.

Same-path verification keeps the signal clean

The same-path retest is the guardrail that keeps one failing request from turning into five unsolved changes. Before switching models, providers, endpoints, keys, prompts, or input files, repeat the request with the same model, endpoint, project, key, payload, input asset, and request format.

That retest answers the question the recovery path depends on:

Only change one variable at a time after that. If the model changes, keep the key, project, endpoint, and payload stable. If the key changes, keep the model, endpoint, and payload stable. If the input file changes, keep the model and request format stable. The goal is not slow debugging for its own sake; it is preserving enough evidence that the next fix is attached to the right branch.

When the branch proves persistent quota pressure, Nano Banana 2 alternative 429 routes can help decide whether queueing, batching, or a route-out makes sense. For non-urgent work, Google’s Batch API documentation is also relevant because it moves work away from live retry pressure.

FAQ

Is Nano Banana API down when I see 503?

Not always. 503 UNAVAILABLE means the request is in an availability or capacity branch, but one request is not enough to declare a broad outage. Retest the same path, check whether other models or endpoints behave differently, and avoid changing keys or prompts until the branch stays stable.

Does billing fix 503 errors?

Billing can affect quota and tier limits, but a proven 503 UNAVAILABLE branch is not a billing fix by default. Keep 429 and 503 separate: quota pressure belongs to project limits, while 503 starts as temporary unavailability or overload.

Why did the API return text but no image?

The response parser may be looking in the wrong place, the request may not have asked for image output, the generation may have ended with a safety finish, or the input file may not be available to the request. Inspect parts and inlineData before treating text-only output as a service failure.

What can Request Denied mean?

It can mean 403 PERMISSION_DENIED, a blocked or invalid key, a project/API permission issue, a safety finish, an invalid file/resource reference, or a gateway-level denial. The fix depends on which owner returned the denial.

Should I switch models or providers immediately?

No. Switch only after branch proof. A route-out can be the right decision for persistent quota, capacity, or policy limits, but changing the model, endpoint, provider, prompt, and key at the same time destroys the evidence needed to know what actually fixed or failed.