> ## Documentation Index
> Fetch the complete documentation index at: https://docs.yingtu.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# API traffic capacity and availability

> Plan Nano Banana traffic around at least 5,000 gateway requests per minute, no fixed platform RPM cap, upstream 429 responses, and a 98% availability objective.

The Nano Banana gateway access layer supports at least **5,000 API requests per minute** and does not apply a fixed platform-side RPM limit to the documented generation and asynchronous-submission routes.

This is a request-ingress capacity statement. It is not a promise that 5,000 images will finish each minute: image completion depends on model duration, request size, the selected upstream model, and official upstream capacity.

## Public service contract

| Area                     | Current scope                                                    |
| ------------------------ | ---------------------------------------------------------------- |
| Gateway request capacity | At least 5,000 API requests per minute                           |
| Fixed platform RPM limit | None on the documented Nano Banana routes                        |
| HTTP `429`               | Official upstream rate, quota, spend, or model-capacity response |
| Availability objective   | At least 98%                                                     |
| Contractual SLA          | Not provided by this documentation                               |
| Service credits          | Not included in this availability objective                      |

<Note>The 98% figure is an operational availability objective. It is not presented as measured historical uptime, a contractual SLA, or a service-credit commitment.</Note>

## What 5,000 RPM means

### Request acceptance is not image completion

RPM counts API requests reaching the gateway. A synchronous request can remain open while a model generates the image; an asynchronous request returns HTTP `202` after the task is accepted and completes later.

Use the [asynchronous task flow](/en/unified-api/async-tasks) when work must survive the client connection or when a burst should be separated from image completion.

### No fixed gateway cap does not remove upstream limits

The gateway does not impose a fixed public RPM ceiling on these routes. Google can still enforce model, project, RPM, images-per-minute, spend, or capacity limits. Other responses such as validation, authentication, balance, and ownership errors remain independent of rate limiting.

## Interpret HTTP 429 as an upstream response

For the documented Nano Banana routes, HTTP `429` indicates that the official upstream provider could not accept the request under its current rate, quota, spend, or model-capacity conditions.

When `429` occurs:

1. Honor `Retry-After` when the response supplies it.
2. Otherwise use exponential backoff with random jitter.
3. Limit retry attempts or set a total deadline.
4. Reduce burst concurrency while the upstream provider recovers.
5. Do not retry `400`, `401`, or `403` as if they were rate limits.

Google documents `429 RESOURCE_EXHAUSTED` for RPM, TPM, RPD, spend-based, project-tier, and model-capacity limits. See the [Gemini API rate-limit documentation](https://ai.google.dev/gemini-api/docs/rate-limits).

## Availability objective

The API targets availability of **98% or higher**. Applications that require continuous production should still plan for transient upstream `429` and `5xx` responses, network timeouts, and model-specific capacity changes.

A resilient client should keep request IDs, use bounded retries, persist asynchronous `task_id` values before returning control to the user, and avoid treating one provider response as a permanent failure.

## Production integration checklist

* Keep API keys and model IDs in configuration.
* Apply a client-side concurrency ceiling that matches your own worker and budget limits.
* Use asynchronous submission for work that cannot remain attached to one HTTP connection.
* Honor `Retry-After` and use bounded backoff with jitter.
* Record `responseId`, `task_id`, model ID, HTTP status, and request time for support.
* Monitor your own completed-image rate separately from gateway RPM.
* Review the [error and retry guide](/en/getting-started/errors-and-retries) before production rollout.

<CardGroup cols={2}>
  <Card title="Handle API errors" icon="rotate-cw" href="/en/getting-started/errors-and-retries">
    Distinguish upstream 429 responses from validation, credentials, balance, and server failures.
  </Card>

  <Card title="Use asynchronous tasks" icon="clock-3" href="/en/unified-api/async-tasks">
    Accept work quickly, persist task IDs, and retrieve terminal results.
  </Card>

  <Card title="Implement bounded polling" icon="refresh-cw" href="/en/unified-api/polling">
    Add Retry-After, jitter, a deadline, and terminal-state handling.
  </Card>
</CardGroup>