Como integrar Gemini Image API en una app: Firebase AI Logic o backend

Si tu app necesita llamar a Gemini image generation directamente desde un cliente movil o web, empieza por Firebase AI Logic. Si controlas un backend de confianza y necesitas mas control de imagen, usa Gemini API del lado del servidor. Esa sigue siendo la respuesta actual mas segura porque Firebase AI Logic es la ruta oficial para llamadas directas desde la app, mientras que el Gemini image API de nivel inferior sigue exponiendo controles que Firebase todavia no muestra.

El error mas costoso en este tema no es de sintaxis. Es escoger mal el limite de seguridad. Una app movil o un frontend publico no deberian incluir una raw Gemini API key. La guia actual de getting started de Firebase AI Logic, revisada el 23 de marzo de 2026, dice de forma explicita que no pongas la Gemini API key dentro del codebase de la app y recomienda activar App Check cuanto antes. Solo con eso, la mayoria de integraciones client-side serias deberian arrancar por Firebase AI Logic.

Hay otra advertencia que debe ir arriba. La guia de image generation de Firebase, tambien revisada el 23 de marzo de 2026, marca Gemini image generation dentro de Firebase AI Logic como Preview, dice que los modelos de imagen requieren Blaze y aclara que aspect_ratio e image_size todavia no estan soportados ahi. Si tu feature depende de tamaños exactos, validacion server-side mas fuerte o un Gemini API surface area mas amplio, conviene mas una ruta en backend.

Resumen rapido

• Usa Firebase AI Logic si tu app movil o web realmente necesita image generation directo desde el cliente.
• Usa un trusted backend route si controlas el servidor y quieres aspectRatio, imageSize, auditoria, storage o una policy de cuotas mas estricta.
• No metas una raw Gemini API key en mobile code ni frontend code.
• Para la mayoria de integraciones nuevas, empieza con gemini-3.1-flash-image-preview.
• Cambia a gemini-3-pro-image-preview solo cuando text-heavy graphics o premium assets justifiquen el coste.
• Antes de exponer la funcionalidad a trafico real, piensa en Preview, Blaze, App Check y limites por usuario.

Si tu duda es mas amplia que la integracion en apps, empieza por Gemini Image Generation Tutorial: App, AI Studio, and API. Si lo que buscas son snippets server-side listos para copiar, abre Gemini Image Generation Code Examples. Si el siguiente problema es de presupuesto, no de arquitectura, te conviene Gemini image generation API pricing.

Elige primero la ruta correcta de integracion de Gemini Image API

La SERP actual mezcla tres trabajos distintos. La documentacion de Firebase responde "como llamo a Gemini desde mi app". La documentacion de Gemini image responde "que soporta el API de imagen de nivel inferior". La documentacion de Android responde "como se ve esto dentro de un stack movil". Si lees esas paginas sin una routing rule, parece que se contradicen aunque en realidad cada una cubre una capa diferente.

La regla util es simple: si el cliente debe llamar a Gemini directamente, usa Firebase AI Logic; si tu backend puede hacerse cargo de la peticion de forma segura, mueve image generation al servidor. Esa decision pesa mas que la eleccion de framework. Pesa mas que Next.js frente a Flutter o Android frente a Web.

Firebase AI Logic gana cuando quieres el shortest secure path para una feature orientada al usuario. Esta pensado para mobile and web apps, incluye App Check en la historia de seguridad y encaja bien en experiencias como "genera una imagen dentro de este chat" o "edita esta foto subida desde la app". Es la mejor respuesta cuando el producto necesita un loop directo entre usuario y modelo.

El backend route gana cuando la app no necesita model access directo desde el cliente. Si ya tienes API boundary, background workers o una capa server-side, el Gemini API de nivel inferior te da un sitio mucho mejor para quotas, prompt validation, logging, storage, moderation y image settings que Firebase AI Logic todavia no expone. Ese es el punto en el que una demo se convierte en una feature de producto.

Tambien existe una ruta intermedia razonable. Muchos equipos empiezan con Firebase AI Logic para iterar rapido en el client-side UX y despues mueven image generation a backend cuando la feature demuestra valor y las limitaciones empiezan a importar. El error no es cambiar de ruta. El error es asumir que ambas rutas son equivalentes desde el dia uno.

Firebase AI Logic es la ruta por defecto para llamadas directas desde movil y web

La overview page de Firebase hoy lo dice bastante claro: si necesitas llamar a Gemini API directamente desde una app movil o web, y no server-side, usa los client SDKs de Firebase AI Logic. Por eso esa debe ser la respuesta por defecto para la rama "dentro de una app" de este tema.

La ventaja no es solo conveniencia. Es el security boundary. El mismo setup flow puede crear la Gemini API key dentro del proyecto de Firebase, pero a la vez te dice que no pongas esa key en el codigo de la app. Tambien empuja a activar App Check en cuanto el proyecto deja de ser un experimento local. Eso es mejor que cualquier tutorial que te diga que pegues una provider key permanente en JavaScript publico.

Esta es la forma web actual con Firebase AI Logic. La estructura sigue el patron oficial, pero en una integracion nueva tiene mas sentido reemplazar el antiguo gemini-2.5-flash-image por gemini-3.1-flash-image-preview como current default lane.

javascript
import { initializeApp } from "firebase/app";
import {
  getAI,
  getGenerativeModel,
  GoogleAIBackend,
  ResponseModality,
} from "firebase/ai";

const firebaseConfig = {
  // ...
};

const firebaseApp = initializeApp(firebaseConfig);
const ai = getAI(firebaseApp, { backend: new GoogleAIBackend() });

const model = getGenerativeModel(ai, {
  model: "gemini-3.1-flash-image-preview",
  generationConfig: {
    responseModalities: [ResponseModality.TEXT, ResponseModality.IMAGE],
  },
});

const prompt =
  "Create a clean onboarding illustration for a budgeting app. Use a calm blue palette and leave room for headline text.";

const result = await model.generateContent(prompt);
const imagePart = result.response.inlineDataParts()?.[0];

if (imagePart) {
  console.log(imagePart.inlineData.mimeType, imagePart.inlineData.data);
}

Hay dos detalles importantes. Primero, Firebase AI Logic devuelve texto e imagen juntos, asi que el cliente tiene que manejar ambos tipos de salida. Segundo, como Firebase AI Logic todavia no soporta aspect_ratio ni image_size, el propio prompt debe seguir llevando pistas de composicion como "deja espacio para el titular" o "hazlo como poster vertical". Funciona, pero tambien deja claro que Firebase AI Logic es la ruta mas simple, no la mas controlable.

Aqui tambien conviene ser honesto con billing. El onboarding mas general de Gemini Developer API dentro de Firebase puede sonar amigable con el free tier, pero para este use case manda el image-generation guide, que es mas estrecho y mas actual: los modelos de imagen de Gemini dentro de Firebase AI Logic requieren Blaze. La forma segura de decirlo no es "esto es gratis" ni "esto siempre sera caro". La forma segura es: el onboarding general puede empezar barato, pero Gemini image generation en Firebase AI Logic hoy es una ruta de pago.

Cuando conviene un backend de confianza

Si tu app ya tiene backend, el Gemini API de nivel inferior suele ser una forma mas sana de integracion a largo plazo. La razon no es postureo. Es control.

La documentacion oficial de Gemini image generation expone imageConfig con controles como aspectRatio e imageSize. La guia de Firebase para image generation, en cambio, dice que Firebase AI Logic todavia no muestra esos controles de forma explicita. Para muchos productos, esa sola diferencia cambia la arquitectura. Si necesitas hero images estables en 16:9, product cards en 1:1, story assets en 9:16 o tamaños distintos para versiones baratas y premium, el backend route te da un contrato mucho mas limpio.

Ademas, el backend route te deja convertir image generation en parte de un business workflow y no solo en un cuadro de prompt. Ahi es mas facil meter abuse filtering, billing por usuario, hooks de moderacion, storage en Cloud Storage o S3, audit logs, admin tools y prompt templates que no deberian llegar al cliente. Todo eso empieza a importar en cuanto la feature deja de ser demo y entra en produccion.

La forma basica server-side en JavaScript sigue siendo esta:

javascript
import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

export async function createMarketingImage(prompt) {
  const response = await ai.models.generateContent({
    model: "gemini-3.1-flash-image-preview",
    contents: prompt,
    config: {
      responseModalities: ["IMAGE"],
      imageConfig: {
        aspectRatio: "16:9",
        imageSize: "2K",
      },
    },
  });

  const imagePart = response.candidates?.[0]?.content?.parts?.find(
    (part) => part.inlineData
  );

  if (!imagePart?.inlineData) {
    throw new Error("No image returned from Gemini");
  }

  return {
    mimeType: imagePart.inlineData.mimeType,
    data: imagePart.inlineData.data,
  };
}

Esta ruta escala mejor para production asset generation, admin-only creative tooling y cualquier caso donde importen tamaños fijos, storage, observabilidad y throttling previo al provider limit. Si te gusta Firebase como stack general pero quieres que la orquestacion la controle el servidor, la propia overview page de Firebase apunta a Genkit como route server-side. Esa es una buena mental model: Firebase AI Logic para direct client integrations, Genkit o tu propio backend endpoint para AI behavior mas complejo y mas controlado.

En web importa mas la frontera de confianza que el nombre del framework

Para una web app, el problema casi nunca es el logo del framework. El problema es donde cae la request boundary.

Si el usuario necesita image generation o image editing inmediato dentro de la interfaz, Firebase AI Logic es el shortest secure path. Tu frontend habla a traves del gateway de Firebase, puedes sumar App Check y no expones una raw Gemini API key en JavaScript publico. Eso encaja bien en creator tools, chat apps con funciones de imagen o editores ligeros.

Si la feature es mas de negocio que de interaccion directa, usa tu propio server route. Un route handler de Next.js, una Cloud Function o un backend en App Hosting es mejor lugar cuando la salida se debe guardar, normalizar, auditar o cobrar con cuidado. Tambien es el sitio natural si la app necesita un tamaño canonico, una prompt policy centralizada y un audit trail.

La division real es esta:

• Frontend Firebase AI Logic route: el usuario pide, la app recibe la respuesta y la experiencia gana por el loop directo.
• Backend Gemini API route: el cliente pide un job a tu servidor y tu servidor decide modelo, image size, aspect ratio, storage y quota behavior.

La mayoria de product teams deberia cerrar esta decision antes de construir componentes reutilizables alrededor de la feature. Si no, acaban empujando a contrarreloj una UX client-side detras de un servidor.

En Android, Firebase AI Logic y App Check son el punto de partida natural

Android es donde Firebase AI Logic se siente mas natural porque Google ya organiza el tema asi. La pagina de Android Developers para Gemini Developer API lleva a los desarrolladores hacia Firebase AI Logic para integracion en apps, y por eso esas paginas pesan tanto en la SERP.

La forma en Kotlin es directa. Igual que en web, lo importante no es solo el SDK call, sino que viva dentro de un proyecto Firebase AI Logic con App Check y una quota policy realista:

kotlin
val model = Firebase.ai(backend = GenerativeBackend.googleAI()).generativeModel(
    modelName = "gemini-3.1-flash-image-preview",
    generationConfig = generationConfig {
        responseModalities = listOf(ResponseModality.TEXT, ResponseModality.IMAGE)
    }
)

val prompt = "Create a 1:1 travel sticker of Seoul at night in a bright flat illustration style."
val response = model.generateContent(prompt)

val image = response.candidates
    .first()
    .content
    .parts
    .filterIsInstance<ImagePart>()
    .firstOrNull()
    ?.image

Ese es un buen first Android path cuando la feature es realmente interactiva y forma parte de la sesion del usuario. Pero incluso ahi hay que pensar como operador. La documentacion de quotas de Firebase AI Logic indica un default de 100 RPM per user, y aclara que los provider limits siguen mandando antes. Eso significa que una Android app con uso explosivo de imagen no deberia vivir para siempre sobre los defaults. Baja el limite por usuario a algo que tu negocio pueda pagar y trata App Check como parte del release checklist.

Si la app Android sirve para generar assets internos, flujos de back office o imagenes caras para un equipo, el backend route vuelve a ser mas limpio. La documentacion de plataforma puede hacer parecer que el direct SDK path es la respuesta para todo, pero en realidad lo es solo cuando la interaccion directa del cliente es el producto.

Seleccion de modelo y cuando cambiar de ruta

Para la mayoria de integraciones nuevas, empieza con gemini-3.1-flash-image-preview. La pricing page y la deprecations page, revisadas el 23 de marzo de 2026, respaldan esa recomendacion. Flash Image sigue siendo el default fast lane, mientras que gemini-2.5-flash-image ya es una legacy lane con fecha de cierre anunciada para el 2 de octubre de 2026.

Conviene pasar a gemini-3-pro-image-preview solo cuando el resultado del producto realmente lo justifica. Normalmente eso significa text-heavy graphics, salidas tipo infografia o premium assets donde una primera pasada floja cuesta caro de rehacer. Si el trabajo es "genera imagenes rapidas dentro de la app", Flash Image es el default fuerte. Si el trabajo es "haz piezas visuales pulidas con mucho texto dentro de la imagen", Pro pasa a ser mas defendible.

Los editing workflows tambien pueden obligar a cambiar de ruta. Firebase AI Logic es fuerte para flujos conversacionales que caben dentro de su contrato app-side. Pero si el workflow crece hacia reference-heavy edits, file pipelines o output guarantees mas estrictos, un server route se vuelve mas atractivo. En la FAQ y troubleshooting page de Firebase AI Logic tambien se indica que Files API de Gemini Developer API no esta soportada a traves de los SDKs de Firebase AI Logic. Esa es otra senal de que los flujos mas complejos pertenecen al backend.

Antes de lanzar: seguridad, cuotas y costes

Esta es la parte que mas siguen minimizando las paginas que rankean.

App Check forma parte de la arquitectura. La setup guide actual de Firebase dice que en el minuto uno de pruebas no hace falta, pero tambien deja claro que hay que activarlo cuanto antes antes de compartir la app publicamente. Si recomiendas una ruta directa desde cliente, App Check pertenece al build checklist principal.

Firebase AI Logic pone una capa de cuotas y Gemini otra. La pagina de quotas de Firebase habla de 100 RPM per user por defecto, pero deja claro que los provider limits prevalecen. La documentacion de rate limits de Google explica que los limites de Gemini se aplican a nivel de project y que los preview models son mas estrictos. La consecuencia operativa es simple: una app puede fallar por dos motivos de cuota diferentes, el gateway de Firebase o el limite del proveedor Gemini.

Pricing debe convertirse en model policy. A fecha del 23 de marzo de 2026, la pricing page lista gemini-3.1-flash-image-preview alrededor de $0.045 por imagen 0.5K, $0.067 por 1K, $0.101 por 2K y $0.151 por 4K. La misma pagina lista gemini-3-pro-image-preview alrededor de $0.134 por imagen 1K o 2K y $0.24 por 4K. Esos numeros deberian moldear los defaults del producto. La mayoria de apps no deberia dejar que todo el trafico termine silenciosamente en la premium lane.

El estado Preview debe cambiar el rollout plan. Image generation en Firebase AI Logic sigue en Preview, y los preview models tienen rate limits mas restrictivos. Eso no significa que debas evitar la funcionalidad. Significa que debes lanzarla con guardrails: feature flags, caps por usuario, tamanos previsibles y mensajes claros cuando la cuota se agote.

Un production checklist realista deberia incluir:

• App Check activado
• RPM por usuario reducido a un nivel que el producto pueda pagar
• una default model policy y una optional premium upgrade path
• logging de modelo, success rate y quota failures
• una decision explicita sobre si las imagenes viven solo en cliente o tambien se persisten en servidor

Si ese checklist se ignora, el primer bug report serio casi siempre sera economico o de abuso, no visual.

FAQ

Puedo llamar a Gemini image generation directamente desde frontend code sin Firebase?

No deberias exponer una raw Gemini API key en frontend o mobile code. Si la feature realmente necesita direct client calls, usa Firebase AI Logic para que la provider key no viva dentro de la app. Si no necesita llamadas directas, deja Gemini image generation detras de tu backend.

Firebase AI Logic soporta imageSize y aspectRatio hoy?

No de forma explicita para Gemini image generation a fecha del 23 de marzo de 2026. La image-generation guide de Firebase dice que esos ajustes todavia no estan soportados ahi, por eso el backend Gemini API route encaja mejor cuando el control exacto de salida importa.

Necesito un plan de pago para Gemini image generation en Firebase AI Logic?

Si. La guia actual de Gemini image generation de Firebase dice que los image-generating Gemini models requieren Blaze con independencia del proveedor Gemini. Ese es el current answer correcto para este use case.

Errores que generan retrabajo en la integracion

El primer error es meter una raw Gemini API key en el cliente. La documentacion actual de Firebase dice de forma explicita que no lo hagas. Si un tutorial sigue sugiriendolo, esta por debajo del quality bar actual para este tema.

El segundo error es asumir que Firebase AI Logic y el Gemini API de nivel inferior exponen los mismos image controls. No es asi. La guia de Firebase dice que aspect_ratio e image_size todavia no estan disponibles ahi, mientras que la documentacion de Gemini image si muestra esos controles. Si el tamano exacto de salida importa, la decision de backend route debe tomarse pronto.

El tercer error es leer el onboarding general de Gemini Developer API como prueba de que Firebase image generation es gratis. Es una fuente demasiado amplia. La image-generation guide, que es mas estrecha y mas actual para este caso, es la que manda y la que habla de Blaze.

El cuarto error es copiar un ejemplo viejo con gemini-2.5-flash-image como si fuera el mejor default actual. Algunos code samples de Firebase todavia lo muestran, pero la supported-model list y la deprecations page ya dejan bastante claro que un proyecto nuevo deberia empezar por gemini-3.1-flash-image-preview.

El quinto error es dejar quota planning para despues. Tanto la quotas page de Firebase como la documentacion de Gemini rate limits muestran que una feature de imagen puede fallar por limites de proyecto o de usuario mucho antes de que el codigo este "mal". Por eso la planificacion de cuotas pertenece a la build phase y no a un apendice.

Si ahora te importa mas el implementation detail que la architecture choice, abre Gemini Image Generation Code Examples. Si el foco ya esta en image editing, te ayudara mas Gemini image-to-image editing. Si estas depurando limites o coste, vuelve a Gemini image generation API pricing y a la documentacion oficial de rate limits.

Conclusion

La mejor respuesta actual a "como integro Gemini Image API en mi app" no es el nombre de un SDK. Es una decision de arquitectura.

Usa Firebase AI Logic cuando la app de verdad necesita llamadas directas a Gemini image generation desde movil o web. Usa un trusted backend route cuando tu equipo controla el servidor y necesita image controls explicitos, observabilidad y cost governance. Mantén gemini-3.1-flash-image-preview como default para la mayoria de trabajo nuevo, sube a gemini-3-pro-image-preview solo cuando el premium output lo justifique y trata gemini-2.5-flash-image como la rama legacy que ya es.

Ese enfoque route-first es el que evita rehacer la integracion mas tarde. Cuando la frontera de confianza esta bien decidida, todo lo demas, desde el SDK call hasta la quota policy, se vuelve mucho mas claro.