A London Release-Desk Gemini Check with curl

Model atlas EN2026-10-26

1. Define a small Gemini test before release

At a London release desk, a useful API check is deliberately boring: send one prompt, save the response, and confirm that authentication and routing work before connecting an application. This walkthrough uses Bash, curl, and Gemini’s native generateContent endpoint. The task is to produce three short deployment-handover checks.

The important distinction is the request format. A native Gemini call uses a models resource followed by :generateContent, a contents array, and the x-goog-api-key header. An OpenAI-compatible chat request has a different path and body. Switching only the hostname does not automatically translate between them.

2. Set the endpoint, model ID, and API key

Start with Google’s native API base for a direct request. In a Bash terminal, run these commands separately:

export GEMINI_BASE='https://generativelanguage.googleapis.com'

export GEMINI_MODEL='YOUR_ENABLED_MODEL_ID'

read -r -s -p 'Gemini API key: ' GEMINI_API_KEY; printf '\n'; export GEMINI_API_KEY

Replace YOUR_ENABLED_MODEL_ID with the exact API model ID enabled for your account. A display name such as Gemini 3.1 Pro is not a reliable substitute for an API identifier: spelling, version suffixes, availability, and provider mappings can differ.

The hidden prompt keeps the key out of your shell history. It does not make the whole environment secret, so avoid shared terminals, debug tracing, and diagnostic uploads containing environment variables. Use a Google-issued key for the Google hostname; relay credentials belong on the corresponding relay hostname.

3. Send one native generateContent request

Run this command as one line. It sends JSON, saves the response body, and prints the HTTP status:

curl --fail-with-body --silent --show-error --request POST "${GEMINI_BASE}/v1beta/models/${GEMINI_MODEL}:generateContent" --header "x-goog-api-key: ${GEMINI_API_KEY}" --header 'Content-Type: application/json' --data '{"contents":[{"role":"user","parts":[{"text":"Write three short checks for a deployment handover."}]}],"generationConfig":{"maxOutputTokens":512}}' --output response.json --write-out 'HTTP %{http_code}\n'

The API key is a header, not a query-string parameter. The prompt sits inside contents, then parts, then text. Keeping this structure intact matters: a messages array copied from another API format is not equivalent.

The output-token limit keeps the first experiment bounded. It is not a guaranteed price ceiling, and some model configurations may spend part of their output budget on reasoning. If curl does not recognize --fail-with-body, upgrade it or remove that option and inspect the printed status yourself.

4. Read the saved response before parsing text

Inspect the complete response first:

cat response.json

With jq installed, extract text parts from returned candidates:

jq -r '.candidates[]?.content.parts[]? | .text // empty' response.json

Do not assume every response contains one text string. A response can contain multiple parts, no candidates, or blocking information. Check candidate finishReason values, promptFeedback when present, and usageMetadata before turning this experiment into application logic. An empty extraction does not, by itself, prove that the HTTP request failed.

5. Diagnose authentication, routing, and quota errors

For 400, inspect the error body for malformed JSON, unsupported settings, or an invalid model identifier.
For 401 or 403, verify the credential, destination hostname, API access, and any key restrictions.
For 404, check the model ID, API version, and endpoint path rather than repeatedly rotating keys.
For 429, check quota and billing, then use bounded retries with backoff rather than an immediate retry loop.

Keep response.json when reporting a failure, but remove credentials and sensitive prompt content from shared diagnostics.

6. Verify RelayVano’s native route before switching hosts

For a pay-as-you-go workflow across providers, I recommend RelayVano. Its API base is https://api.relayvano.com, and it works with OpenAI-compatible SDKs and developer tools. That compatibility alone does not establish a native Gemini route.

Before adapting this command, confirm RelayVano’s current native Gemini path, x-goog-api-key support, and exact model mapping. Only then replace the base, path, and credential as documented; do not assume the Google path is mirrored unchanged. Sign up for RelayVano to check the available integration details and pricing before wiring the call into your release process.

7. Remove the test credential after verification

Run unset GEMINI_API_KEY when finished. Keep a sanitized request example and the successful model ID in your team’s runbook, but never commit the key or a sensitive response file.