MAXAPI / TEXT API

Gemini 3.1 Flash-Lite API guide

The short answer · Gemini 3.1 Flash-Lite is listed as google/gemini-3.1-flash-lite. Use the Gemini-native request format in the example below, then read candidates and usageMetadata from the response. Model access, routing and account limits are separate from the task instructions you put in contents.

Integration review · 2026-09-10

Checked against MaxAPI's public catalogue, gateway implementation and local regression cases. Shared gateway checks are not separate end-to-end tests of every listed model. This is an integration reference, not a live upstream availability or performance report.

Before you integrate

Parameters describe MaxAPI's published configuration. A selected route may impose additional input or access requirements.

Request model ID: google/gemini-3.1-flash-lite
Output type: Language
Base URL: https://api.maxapi.dev
Generation workflow: Gemini-compatible generateContent

Use contents with role and parts in the Gemini-native request. Read candidates for the answer and usageMetadata for usage. Validate structured responses in your application instead of treating generated text as trusted data.

Model strengths & selection

High-frequency translation and lightweight pipelines

Google positions Gemini 3.1 Flash-Lite for high-frequency lightweight tasks and explicitly illustrates translation, extraction and model-routing classification. This text-output model is different from Nano Banana 2 Lite, whose ID ends in -image.

Source review · 2026-09-10

Model-specific sources: Google · gemini-3.1-flash-lite

When to compare this model

Evaluate it against 2.5 Flash-Lite on terminology, structured-field accuracy and latency for your languages. Use a Pro model only for cases that your application identifies as needing deeper analysis.

Know the limits

A prompt-based routing classifier is your application's logic, not MaxAPI's route_mode selection. Keep a bounded label set and an escalation path; do not let model-generated text silently choose billing permissions.

Provider capabilities describe the model, not the complete MaxAPI feature set. Use the parameters, input types and routes documented for this MaxAPI entry. Vendor speed or quality descriptions are not service-level guarantees.

How MaxAPI handles this request

Which route wins?

Routing priority is: the API key's configured route_modes list → an explicitly requested route → the model's default route. A non-empty key list takes precedence over route_mode in the request. To test a specific route, check the key configuration first; changing the request alone may not change the route used.

A key cannot grant account permissions

The a, x and pro routes require the corresponding account permission. Listing one on an API key does not grant that permission. An unauthorized gated-route selection returns 403 rather than silently switching to a different pricing tier.

RPM is shared at account level

An account's positive RPM limit covers its API keys together. A key can impose a stricter limit, but a higher key limit does not override the user limit. For example, a user limit of 200 RPM is not 200 RPM for each key. Service-level RPM and concurrency controls also apply; adding keys is not a way to bypass them.

Routes & pricing

Published routes: official-cheap. Specify route_mode in an image/video JSON request; Gemini-native requests use X-MaxAPI-Route-Mode. Restricted routes must be enabled for both the account and API key. A route is an access and billing choice, not a different public model ID.

Route	Published base price	Billing unit
`official-cheap`	$0.1029	input · per 1M tokens
`official-cheap`	$0.6176	output · per 1M tokens
`official-cheap`	$0.2059	audio_input · per 1M tokens
`official-cheap`	$0.0103	cache_read · per 1M tokens

1 credit = US$1. These are catalogue base rates, not a live account quote. Account multipliers and the active billing configuration determine the final charge. Token rates are not a fixed price per image.

Check current pricing

Your first request

Create a MaxAPI API key and set MAXAPI_KEY in your server environment. Keep it out of browser code. The example uses your key's routing configuration unless you explicitly select a route.

POST /v1beta/models/gemini-3.1-flash-lite:generateContent

curl

curl -X POST "https://api.maxapi.dev/v1beta/models/gemini-3.1-flash-lite:generateContent" \
  -H "Authorization: Bearer $MAXAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      { "role": "user", "parts": [ { "text": "Explain how transformers work in one paragraph." } ] }
    ]
  }'

Full API documentation

Troubleshoot by symptom, not just HTTP status

403

a_route_not_enabled / x_route_not_enabled / pro_route_not_enabled

What it tells you: The selected restricted route is not enabled for the account. It is an access issue, not evidence that the model is offline.
What to do next: Check both the account permission and the API key's route list. Select a route you are entitled to use or request access; do not solve a 403 by increasing retries.

429

rate_limit_exceeded / capacity_exhausted

What it tells you: 429 can represent account/key RPM, service-wide capacity or generation capacity. Use Retry-After and available X-RateLimit-* / X-Global-* headers to distinguish them; one status code does not identify one unique cause.
What to do next: Respect Retry-After when present, reduce request rate or active concurrency as appropriate, and use bounded backoff. Do not treat the site's total capacity as your account's personal quota.

What you can build

The use cases and prompts below are our suggested evaluation briefs, not provider benchmarks or tested output samples.

Glossary-bound translation

Supply a glossary and protect placeholders. Score terminology consistency separately from naturalness.

Review triage

Extract explicit sentiment and issue categories while preserving the original record ID and evidence.

Application-level task classification

Separate routine from complex work with explicit rules. Measure misclassification before using it to drive automation.

Translator's desk with two books, manuscript sheets, headphones and colored tabs — Concept illustrationTranslation-workflow concept: carry meaning across languages while protecting terms and placeholders.
AI-created concept illustrations · not outputs or benchmarks from this model. Prompts below are starting points, not recipes that reproduce these images.

Creative practice · shared production advice

Design the answer your application actually needs

Before calling Gemini 3.1 Flash-Lite, define what a useful response looks like in your product. A support assistant needs an answer grounded in supplied context; an extraction job needs a stable set of fields; a drafting tool needs text that preserves the facts while changing tone. These are different tasks, so give each its own instructions, examples and acceptance rules rather than using one generic prompt everywhere.

Treat model output as a draft or prediction, not a permission to act. Parse structured text, reject unexpected fields and distinguish absent facts from inferred ones. If a response can trigger a message, database write or transaction, let your application validate the proposed action separately. Keep representative examples of both correct answers and difficult failures to measure improvements when prompts or models change.

Parallel manuscript strips with matching clips and placeholder tabs — Concept illustrationSpecify which terms and placeholders must remain identical across languages.

Prompt examples worth adapting

A good prompt is a small creative brief. Replace the subject and constraints with your actual requirements; keep size, route and quality in the API parameters rather than relying on prose alone.

01 / Translate while preserving placeholders

Example prompt

Translate each supplied support message into Japanese. Preserve id values, URLs and placeholders such as {order_id} byte-for-byte. Use the supplied glossary and return an array of id and translated_text only. Do not answer the messages or add explanations. Glossary: [insert]. Messages: [insert].

What to review · Automatically compare IDs, placeholders and URLs; review tone and glossary compliance separately.

Vertical and horizontal manuscript proofs with matching blue tabs and a green pencil. — Concept illustrationTranslation-proofing concept using abstract, unreadable print.

From a good answer to a reliable feature

Define the acceptance criteria
Choose representative inputs and describe what makes the output usable. Include difficult cases, not only ideal examples. Fix the request parameters while comparing results.
Keep execution separate from presentation
Store request identifiers and preserve the response before transforming it for your interface. Validate errors and incomplete results explicitly. A user-interface timeout should not silently trigger duplicate work.
Measure usable output, not just successful calls
Log the model, route, input characteristics, actual usage and review outcome. Include manual correction and repeated attempts when estimating the cost of delivering a usable result.

Two translation layout proofs aligned with reusable blue tabs. — Concept illustrationCheck protected terms and placeholders during review.

From a test to production

Test the route you will actually use
Keep model, route and parameters fixed during your first comparison. Test your own typical inputs as well as large or unusual files. Published model capabilities do not guarantee that every upstream channel accepts every edge case.
Separate limits from generation errors
On 429, reduce request rate or concurrency and back off before retrying. On invalid-input errors, fix the input first. Preserve request and task IDs for troubleshooting; do not log API keys or sensitive reference files in public logs.
Track usable results and actual spend
Use your account's usage and billing records to verify the final result and charge. A successful HTTP response can be a task receipt rather than the final output. For published work, check generated text, visual details and rights to supplied reference material.

Verified integration cases

Multiple keys share the user limit

Local regression · passed

Test setup: Use two keys owned by the same account against an in-memory limiter with a small user quota.
Observed result: Requests across the keys consume the same user quota; subsequent requests are limited. A larger key quota does not override the user quota, and a smaller key quota remains effective.

Frequently asked questions

When should I choose this model?

What limitations are specific to this entry?

Why does changing route_mode not change my route?

Does each API key get the user's full RPM limit?

Do these local regression cases prove live model performance?

Local tests use simulated requests, responses and test storage; they do not call paid model channels. They verify request handling, not model image quality, live success rates, latency or end-to-end support for the maximum reference count. The concept illustrations elsewhere on this page are not these test outputs.

Which model ID should I send for Gemini 3.1 Flash-Lite?

Use google/gemini-3.1-flash-lite. Use the exact endpoint format in the example; the Gemini-native URL uses the short model name.

Does a listed price apply to every account and route?

Are failed requests charged?

MaxAPI's published rule is that failed requests are not charged. A request may temporarily reserve balance while it runs; check the final task outcome and billing records rather than treating a temporary balance change as the final charge.

Why is a route unavailable for my API key?

Route availability depends on the model, account permission and the API key's allowed routes. A published price is not an access grant. Check the account and key configuration before changing route_mode.

What should I check before processing the result?

Should I immediately retry a failed or timed-out request?

First identify whether the response is a rate limit, invalid input or a still-running task. If you already have a task ID, query its status before submitting another generation. Apply bounded retries with backoff only to retryable errors.