Handle 429 and retries without a request storm
Distinguish request rate from concurrency, avoid unbounded retries and keep task polling separate from new generation submissions.
Technical review:
RPM is not concurrency
RPM measures new requests over a minute; concurrency measures work still in flight. Even modest RPM can create many active jobs when generation takes a long time. Your integration needs both a submission-rate control and a cap on active work. Do not copy a limit from a screenshot or another customer’s account: platform, key, model and upstream limits can differ, and limits can change. A faster client cannot override available upstream capacity.
Classify a 429 before retrying
HTTP 429 indicates too many requests. A server may include Retry-After, but clients must not assume it is always present. On MaxAPI, inspect the error code and request record to distinguish an admission rejection from an upstream rate limit or a failed task. Pause or reduce new submissions and preserve existing task IDs. A user-level request may contain multiple channel attempts; channel attempt counts are not a reliable substitute for your own count of unique submitted jobs.
Use separate retry policies for GET and POST
A transient GET polling failure can be retried against the same task, with bounded backoff and jitter. Repeating a generation POST can create new work and extra cost. The downloadable examples deliberately stop on HTTP or network errors rather than automatically resubmitting. If your application later adds retries, first establish whether the original task exists, honor a valid server delay, cap total attempts, and provide an operator-visible failure state. Do not retry unchanged invalid inputs or evade safety restrictions.
Measure accepted work and outcomes separately
Track unique job submissions, accepted tasks, active tasks, terminal failures and polling traffic separately. Include request and task IDs in restricted diagnostic logs, but exclude keys, private prompts and full reference URLs. Lower concurrency when queues grow rather than letting client retries amplify the load. Decide your own bounded queue size and user-facing wait policy; these are application controls, not a promise that all queued jobs will finish within a fixed time.
Model-specific parameters
Public configuration snapshot; not live availability. Follow each model page for its parameters, supported routes and reference limits.
- Gemini 3.1 Flash Image Preview
google/gemini-3.1-flash-image-preview - Nanobanana Pro
google/gemini-3-pro-image-preview - GPT Image 2
openai/gpt-image-2