Moving from Imagen to Nano Banana in the Gemini API: A Step-by-Step Guide

What you’ll learn in this guide

According to Google’s Gemini API documentation, Imagen models have been shut down and are no longer available through the API. When migrating an image generation integration that depends on Imagen, you therefore need to address three areas together: the model name, the call method, and how the response is handled. This guide explains how to review these changes in your existing integration.

This is a migration checklist for applications and workflows that use the API. The source documentation does not include setup commands for a specific programming language, a package version, or a complete code example. For that reason, this guide does not provide sample code or UI steps that aren’t in the source.

Requirements and preparation

The migration covers Imagen integrations that generate images through the Gemini API. The source does not specify account type, pricing, quotas, or hardware requirements. Before starting, a useful first step is to identify your project’s existing API calls and the parts of your application that use the image response.

List where Imagen model names appear in your codebase, configuration files, or request templates. Then note which method is used for image generation and which part of the API response your application consumes. This review shows that you may need to make changes not only to the request itself, but also to the code that processes the response.

Step-by-step migration to Nano Banana

1. Identify the current model name. Find the requests that use Imagen and check which model name your application calls. Google recommends using gemini-2.5-flash-image instead of Imagen model names, or switching to Nano Banana 2 models such as gemini-3.1-flash-image. When choosing an option, update the part of your integration that selects the model, and check whether multiple requests use the same setting.

2. Change the call method. Google’s migration notes say to use client.models.generate_content instead of client.models.generate_images, the method used with Imagen. Treat this as a separate check from updating the model name. Changing the model name alone does not complete the migration if the application still calls the old method.

3. Review response handling. Nano Banana returns image data as content parts, rather than in the dedicated image response object you might expect from previous usage. Check which structure your application reads where it receives the API response. Also trace how the image data is passed to subsequent steps in the application.

4. Validate the flow in your application. After updating the model name and call method, test the end-to-end flow with an image generation request. Check not only that the request is sent, but also that the image data in the response reaches the next step as expected. Because Google’s migration notes don’t provide a specific test scenario or expected output, the scope of testing should be determined by how your application is used.

5. Clean up old references and documentation. Your code or internal technical notes may still refer to Imagen model names or the old response format. Updating them reduces the risk of setting up a new integration based on a discontinued model or method during future maintenance. This is not a new API feature, but a maintenance recommendation to keep the migration clear.

Common mistakes

Changing only the model name: Google’s migration guidance calls for reviewing the method and response handling, along with the model name. Checking all three is important for assessing whether the integration is ready for the new setup.

Expecting the old response structure: Since Nano Banana returns image data in content parts, parts of your application written for an earlier image response object may not find the data as expected. Include the response-consuming component in your migration plan.

Assuming requirements not stated in the source: The migration notes do not specify a particular language or package version, pricing, quotas, or account requirements. Rather than treating these as confirmed requirements, check the latest Gemini API documentation before implementing the changes.

Testing only whether the request was sent: A successful request does not, by itself, confirm that the image data in the response is being used correctly in subsequent steps. Include response handling in your test coverage.

Impact on architecture, interior design, and archviz workflows

For teams using image generation through the Gemini API for concept work, interior design alternatives, or other visual generation steps, this change means updating the existing integration. If an automation depends on Imagen, review the model name, call method, and response-consuming component together. Applications that pass generated image data to another step in a project workflow should also check that the handoff is compatible with the new response format.

The source does not specify local hardware requirements, so it is not possible to infer a specific workstation or GPU requirement for this migration. Pricing and usage terms are also not explained. It makes sense for offices and visualization teams to review the API usage terms separately before migrating, and to test their existing automation against the model, method, and response changes.

Next steps

First, inventory the calls that depend on Imagen. Then evaluate one of the model names recommended by Google and the new call method; finally, verify how your application processes the response parts containing image data. For more detailed examples, Google points to its image generation guide. For implementation details not covered here, consult the latest official documentation.

Source and license

This guide is adapted from Google’s official English-language guide to using Imagen in the Gemini API and migrating to Nano Banana. Unless otherwise noted, the source is licensed under CC BY 4.0. The text has been adapted into Turkish; no code examples not found in the source have been added.