Gemini API Proxy: Why the Second Tool Call Fails

The first request works.

Gemini reads your prompt, chooses a function, and returns sensible arguments. Your application runs the lookup and receives a result.

You send that result back.

The next request fails.

At this point, changing the API key is tempting. So is switching models, increasing the timeout, or retrying the same request through another gateway.

But the missing piece may be in the response you already received.

A Gemini tool conversation can depend on protocol state that your application never displays to the user. If a client, proxy, or history serializer removes that state, a successful first request can lead to a broken continuation.

This article follows an illustrative debugging scenario. It is not a report of a measured incident or a claim that a particular provider caused a failure.

The conversation looked complete

Imagine a developer building a small assistant that checks whether a document exists.

The visible interaction seems straightforward:

1. The user asks for a document.
2. Gemini requests a lookup.
3. The application returns the lookup result.
4. Gemini writes the answer.

The application stores a clean transcript:

{
  "role": "assistant",
  "text": "",
  "tool_name": "find_document",
  "arguments": {
    "document_id": "DOC-104"
  }
}

That record may be adequate for a debugging screen.

It may be inadequate for replaying the model conversation.

The developer has replaced the provider’s response with a smaller application-specific object. Any fields not listed in that object disappear.

The important question becomes: what did the application remove?

What thought signatures contribute

Google describes thought signatures as encrypted reasoning-state representations. Their location and handling depend on the API protocol.

In generateContent, signatures can be attached to content parts. In the Interactions API, reasoning is represented through dedicated thought steps; stateful and stateless operation handle continuation differently.

Google’s Gemini thinking documentation explains these distinctions.

A signature is not a readable chain-of-thought transcript. Your application does not need to interpret or summarize it.

It does need to preserve the state required by the protocol it uses.

That is why “we saved the assistant’s text” is not a sufficient description of conversation storage for a tool-using Gemini integration.

The first clue is where the failure begins

Before blaming the gateway, establish the boundary.

Does the failure happen:

• On the first text-only request?
• When tools are introduced?
• After the first tool result is returned?
• Only after storing and reloading the conversation?
• Only when switching from non-streaming to streaming?

Each answer points to a different part of the integration.

A first-request authentication failure is not a signature problem.

A continuation that works in memory but fails after loading from your database is a strong reason to inspect serialization.

A conversation that works with a provider’s supported SDK history handling but fails in a custom adapter suggests that the adapter may be discarding or transforming required information.

These are debugging hypotheses, not conclusions. Keep the original response and compare it with the actual outgoing continuation.

Follow one response through the whole path

A Gemini request through a relay can pass through several components:

Use a small synthetic conversation for this inspection. There is no need to collect production conversations or expose sensitive prompts.

For a generateContent integration, capture the selected model content object before the application transforms it. Then capture the corresponding object that will be placed back into history.

Compare those two structures locally.

The point is not to keep the entire HTTP response envelope forever. It is to avoid rebuilding a required model history object from an incomplete display representation.

A local check for accidental field loss

The following helper compares a captured content object with the version your history serializer intends to resend:

def assert_history_round_trip(original_content, restored_content):
    if original_content != restored_content:
        raise ValueError(
            "Model content changed during history serialization. "
            "Inspect removed fields, part order, and transformed values."
        )

Use it with objects obtained from your own synthetic test.

This is a serialization check, not a complete Gemini integration test. It does not establish that the gateway forwards every field correctly upstream, and it does not validate tool-result formatting.

It can, however, identify a common local error immediately: the application receives a complete object and then saves only the text.

For a controlled debugging run, prefer a lossless representation of the protocol’s supported history object. Keep a separate, simplified representation for your user interface.

Do not mix the three protocol shapes

There are three interfaces developers may encounter:

• Gemini generateContent.
• Gemini Interactions.
• OpenAI-compatible chat interfaces.

They are not interchangeable JSON envelopes.

The Google OpenAI compatibility guide documents an OpenAI-style access path. That does not mean fields from a native Gemini response can be copied into arbitrary positions in messages.

Likewise, an Interactions identifier is not a generic conversation ID that every API relay understands.

Choose one protocol for the test. Follow its continuation rules throughout the full tool cycle.

If you later move to another protocol, treat that as a migration with its own verification. Do not change the URL and assume all stored conversations remain portable.

What this means when choosing a Gemini API gateway

For a gateway-backed integration, “Gemini supported” is only the beginning of the conversation.

You need to know whether the selected route supports the protocol and continuation behavior you actually use.

4SAPI publishes a native Gemini endpoint guide. It documents the generateContent path and states that native Gemini format requires the corresponding group selection.

Its example uses an older model identifier. Use the exact current identifier available in your account; do not treat the example as a recommendation for a current model release.

The documentation of a native endpoint also does not, by itself, prove Interactions support or successful signature preservation for every Gemini model.

A practical provider question is:

> Can this Gemini model route complete a tool call and accept the tool result on the next turn without losing required thought signatures or other continuation metadata?

Ask for a demonstration using the protocol you plan to deploy.

A small test that tells you more than “hello world”

Build a development tool that always returns a fixed result:

{
  "document_id": "DOC-104",
  "exists": true,
  "title": "Example Document"
}

Then perform one full conversation:

1. Ask Gemini to check DOC-104.
2. Receive the tool call.
3. Preserve the required model response state.
4. Return the fixed tool result using the protocol’s expected format.
5. Receive a completed user-facing answer.
6. Save the conversation and repeat the continuation from restored history.

Do not use a real document system for this first test. A fixed response removes database permissions, search relevance, and network delays from the experiment.

Record whether the answer correctly uses the fixed tool result. A request that returns HTTP 200 but ignores the result should not automatically count as success.

Only after this works should you introduce streaming or more complicated tool behavior.

Why switching routes can complicate the investigation

If you change the model, API protocol, token group, and client library at the same time, a successful retry will tell you very little about the original failure.

Change one variable at a time.

Start a clean synthetic conversation when testing a different route. Do not assume provider-managed state identifiers remain usable across gateways or accounts.

For client-managed history, follow the destination protocol’s documented requirements. Avoid inserting invented signatures or placeholders to make validation pass. That can hide the loss of state instead of fixing it.

The useful result is a repeatable conversation, not one request that stops producing an error.

What to send when you need support

A concise support report should contain:

• Exact model ID.
• Gateway group and endpoint path.
• Client library and version.
• Whether streaming is enabled.
• The stage at which the request fails.
• A sanitized synthetic request pair.
• Request identifiers, when available.

Do not send your API key.

Also distinguish “the provider response did not include this field” from “our application did not save this field.” Those statements locate the problem on different sides of the boundary.

For account and model setup, see the 4SAPI getting-started guide. For identifying the associated request in the dashboard, use the 4SAPI usage-log guide.

Evaluate a gateway with the conversation you will actually run

If your application only sends independent text prompts, a multi-turn tool test may be unnecessary.

If your application uses Gemini to call tools, a text-only demo leaves the most important part untested.

You can start with a 4SAPI account, identify the relevant Gemini route, and confirm that one complete synthetic tool conversation survives both the gateway and your own history storage.

That is a meaningful reason to adopt an API relay: it supports the model behavior your application needs through an integration you can understand and reproduce.