Gemini Interactions API: The June 8 Hard Removal Is Done — Here's What Breaks and How to Fix It

If you built anything on the Gemini Interactions API and haven’t touched your code since early May, there is a good chance your integration is silently broken. June 8, 2026 was the hard removal date for the legacy outputs-based response schema. No extensions, no opt-outs, no grace period. The old shape is gone.

Here is a clear picture of what changed, what is now failing, and exactly what you need to do to get back on track.

What actually happened on June 8

Google ran a three-stage migration window for the Interactions API:

May 7 — opt-in headers enabled, new schema available for early adopters
May 26 — new schema became the default for all requests
June 8 — legacy schema permanently removed from the API

If your code was still relying on the old outputs array in API responses after June 8, your requests are now returning shapes your parser does not recognise. The outputs field no longer exists in the response object.

It is worth noting that the standard generateContent API is not affected by any of this. If you are running production workloads through generateContent, nothing has changed for you.

The core schema change: `outputs` is now `steps[]`

The old Interactions API response returned a flat outputs array. Simple enough for a single text response, but increasingly awkward for agentic workflows where the model reasons, calls tools, runs searches, and produces output across multiple steps.

The new response structure returns a steps array. Each step has a type field that tells you exactly what happened at that point in the interaction. The types you will encounter include:

model_output — the model’s generated text or content
thought — internal reasoning steps
function_call / function_result — tool use
google_search_call / google_search_result — grounded search

A full interaction timeline, retrieved via GET /interactions/{id}, includes everything from the initial user_input step through to the final model_output. A POST /interactions response returns only the output steps from that turn.

This structure is what enables two capabilities Google has been building toward: mid-flight steering (redirecting an interaction while it is in progress) and asynchronous tool calls (where the model does not block waiting for a tool result).

`response_format` replaces `response_mime_type`

The second significant change is how you specify output format. The response_mime_type field is gone. In its place is a unified response_format field that lives at the top level of your request.

response_format is polymorphic. Each entry has a type discriminator (text, audio, image) and type-specific configuration. If you want multiple output modalities, pass an array of format entries. The image_config field has also moved out of generation_config and into response_format, making it the single place for all output type configuration.

What is broken if you missed the window

Any code that reads response.outputs will now either throw an error or silently return undefined/null, depending on how your parser handles unexpected shapes. The most common failure modes:

Direct field access — response.outputs[0].text throws immediately
Iteration over outputs — a for loop over outputs iterates over nothing
Function call extraction — code that looked for function calls in outputs will miss them entirely, since they now appear as typed steps
Stateless history management — if you were collecting outputs from each turn and sending them back as context in the next request, that pattern is now broken

For streaming integrations, there is also a new interaction.requires_action event that fires when the model is waiting for a tool result. If you are doing function calling over streaming and have not handled this event, requests will hang.

The migration checklist

The official migration guide covers this in detail, but the core changes are:

Update response parsing to read from response.steps instead of response.outputs
Handle both user_input and model_output step types in your step processing logic
Update function calling code to find function_call steps in the steps array
Update server-side tool handling to process tool-specific step types like google_search_call
Fix stateless history by collecting the steps array from each response and passing it in the input field of the next request, with your new user turn appended as a user_input step
Replace response_mime_type with a mime_type field inside response_format
Add interaction.requires_action handling if you use streaming with function calls

For the mechanical parts of this migration, Google has an automated tool in the Gemini Skills Library. Running /gemini-interactions-api migrate my app via Gemini CLI or Jules handles the repetitive code changes.

How to confirm you are compliant

The fastest check is your SDK version. Python SDK 2.0.0 or later and JavaScript SDK 2.0.0 or later automatically adopt the new schema. Older 1.x versions worked until June 8 and are now incompatible.

Beyond the SDK version, verify:

Response parsing reads from response.steps, not response.outputs
Output format configuration uses response_format, not response_mime_type
Function-calling and tool code traverses typed steps rather than a flat array
No remaining references to Api-Revision: 2026-05-07 headers (the temporary opt-out that expired June 8)

You do not need to manually traverse the full steps array to get the final model response text. The Google GenAI SDKs expose convenience properties directly on the returned Interaction object. The most commonly used one is .output_text, which automatically extracts and joins the consecutive text content blocks from the model’s response. So for simple use cases, the migration really is just updating your SDK version and switching from response.outputs to the convenience properties.

Why the new structure matters beyond the migration

The steps[] schema is not just a tidier response format. It is the foundation for the agentic capabilities Google is shipping next. New features released after May 7 are only surfaced through steps responses. If you stay on the legacy schema (which you now cannot, since it is removed), you would miss iterative model improvements and new multimodal features as they arrive.

The flat outputs array was designed for single-turn text generation. The Interactions API is designed for multi-turn, multi-step agentic workflows with server-side state. The schema now reflects that purpose properly.

The full technical reference is at ai.google.dev/api/interactions-api, and the migration guide is at ai.google.dev/gemini-api/docs/interactions-breaking-changes-may-2026.