Qué cambió este año en las APIs de Google — y exactamente qué hacer al respecto

Todo el año en una frase

Dos cortes con fecha romperán tu stack si los ignoras — la Content API for Shopping se apaga el 18 de agosto de 2026, y los Dynamic Search Ads pasan automáticamente a AI Max en septiembre de 2026 — y un tercer cambio, la nueva cadencia de releases mensual, deja obsoleta tu versión de la API en silencio, más rápido que antes. Todo lo demás que Google lanzó este año es oportunidad, no obligación. Este artículo aborda cada cambio igual: qué cambió, por qué importa para tu cuenta, y la llamada, el payload o la migración exactos a ejecutar — por orden de prioridad, la fecha más dura primero.

No voy a dejar nada en un «deberías migrar». En cada paso está el artefacto concreto — el endpoint que reemplaza al antiguo, el payload del experimento, la query GAQL — para que veas exactamente qué construir antes de que llegue la fecha.

Una palabra sobre por qué esto importa siquiera. Durante años, las APIs de Google Ads y Merchant fueron una superficie de cambio lento que podías tocar una vez al año. Eso se acabó. La plataforma ahora lanza cada mes, dos de sus mayores superficies se están apagando, y el control que antes sostenías a mano se le está entregando a los modelos. Las cuentas que salen ganando son las que trataron este año como un proyecto de migración, no de mantenimiento.

Fecha límite #1 — Content API for Shopping → Merchant API (18 ago 2026)

Es la fecha más dura del año, así que va primero.

Qué cambió. La Content API for Shopping v2.1 se apaga el 18 de agosto de 2026. Su sucesora, la Merchant API v1, llegó a GA en julio de 2025, y la intermedia v1beta ya se apagó el 28 de febrero de 2026. El viejo monolito se reemplaza por sub-APIs específicas — datasources, products, inventories, reports, notifications.

Por qué importa para tu cuenta. Todo lo que toca tu feed a través de la API antigua deja de funcionar ese día: subidas de feed, feeds suplementarios, custom labels, actualizaciones de precio y stock, lecturas de rechazos. No es un «estaría bien migrar» — es un corte duro. Si un script diario mantiene tus precios sincronizados, enmudece el 18 de agosto y tu feed se va quedando desactualizado poco a poco hasta que alguien repara en los ingresos perdidos.

Qué hacer. Reconstruye contra la estructura de sub-APIs. La forma de la migración es mecánica — cambian el host, la ruta y el modelo de recursos, la intención se mantiene. Aquí tienes el antes/después de la llamada más común de todas, un upsert de producto:

# OLD — Content API for Shopping v2.1 (off on 2026-08-18)
curl -X POST \
  "https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "title": "...", "price": {"value":"19.90","currency":"EUR"} }'

# NEW — Merchant API v1 (productInputs sub-API)
curl -X POST \
  "https://merchantapi.googleapis.com/products/v1/accounts/{account}/productInputs:insert?dataSource=accounts/{account}/dataSources/{ds}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "channel": "ONLINE", "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "attributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Los hosts de los endpoints y la división en sub-APIs salen de la documentación de Google; confirma el cuerpo exacto de la petición para tu recurso contra la referencia de la Merchant API antes de desplegar — cambiaron los nombres de campo, no solo la URL.)

El destino es genuinamente mejor que aquello que reemplaza, que es la parte que nadie te cuenta. Tres mejoras que heredas gratis al migrar:

Si llevabas tiempo queriendo robustecer tu instrumental de feed, el cierre es la excusa perfecta: reconstruye una vez y sal con mejor gestión de errores y menos idas y vueltas de las que la v2.1 permitió jamás.

Fecha límite #2 — Dynamic Search Ads → AI Max (sep 2026)

El segundo cambio con fecha, y el que redibuja cuánto control conservas.

Qué cambió. AI Max for Search llegó a GA el 15 de abril de 2026 tras haber arrancado en beta en mayo de 2025. A partir de septiembre de 2026, Google pasa automáticamente todos los DSA restantes, los recursos creados automáticamente y la concordancia amplia a nivel de campaña a AI Max. Después de eso no podrás crear una campaña DSA nueva — ni en la interfaz, ni en el Editor, ni por la API.

Por qué importa para tu cuenta. El trato es control a cambio de incremento. Con el conjunto completo de funciones — concordancia por término de búsqueda más personalización de texto más expansión de la URL final — Google reporta en torno a un +7 % de conversiones o valor de conversión frente a la concordancia por término sola. A cambio, le entregas al modelo la concordancia, el texto de los recursos y la elección de la URL de destino. Si tienes reglas de marca o de cumplimiento incrustadas a mano en tu configuración DSA, un upgrade silencioso en septiembre puede empezar a mandar tráfico, sin avisar, a URLs y textos que no aprobaste.

Qué hacer. No esperes a descubrir qué le hace el upgrade a tus números — mídelo ahora. Google lanzó las salvaguardas y los puntos de medición a través de la API al ritmo de la función, así que puedes hacer un A/B del cambio con tus propios datos antes de que sea obligatorio:

El movimiento práctico es el último: crea un experimento ADOPT_AI_MAX en todas las cuentas, déjalo correr, y luego lee el delta real con una consulta GAQL normal — en vez de enterarte cuando el upgrade ya sea irreversible:

-- After ADOPT_AI_MAX runs: read the keywordless match, then the trial delta
SELECT campaign.name,
       metrics.conversions,
       metrics.conversions_value,
       metrics.cost_micros
FROM targeting_expansion_view
WHERE segments.date DURING LAST_30_DAYS

(ADOPT_AI_MAX es uno de los nuevos tipos de experimento lanzados en la v24.1; targeting_expansion_view es el recurso de reporting de la v22. Confirma la disponibilidad de campos contra las notas de la versión que llames.)

Fecha límite #3 (continua) — releases mensuales, vida útil más corta

No es una sola fecha, sino un reloj que ahora corre siempre.

Qué cambió. Desde la v23 (28 de enero de 2026), la Google Ads API pasó a una cadencia de releases mensual: cuatro versiones mayores al año más versiones menores mensuales, con un año de soporte por versión mayor.

Por qué importa para tu cuenta. Acceso más rápido a funciones, y obsolescencia más rápida. Las versiones caducan según un calendario publicado — la v20 llega a su fin de vida en junio de 2026, la v21 en agosto, la v22 en octubre. Un salto menor mensual no rompe nada; saltarte un cierre de versión mayor significa que tus scripts empiezan a devolver errores sin más aviso que una fecha en un calendario que no estabas mirando.

Qué hacer. Fija tu versión y vigila el calendario de cierres. El seguro más barato es una comprobación recurrente que sepa qué versión llamas y avise ~60 días antes de que caduque — la propia API te devuelve la versión de la petición, así que la comprobación son unas pocas líneas:

# Recurring guardrail: alert ~60 days before your pinned version sunsets.
from datetime import date

PINNED = "v22"                 # the version your client is pinned to
SUNSET = {"v20": "2026-06-01", "v21": "2026-08-01", "v22": "2026-10-01"}  # from sunset-dates page
sunset = SUNSET.get(PINNED)    # None until your version reaches the published calendar
if sunset and (date.fromisoformat(sunset) - date.today()).days < 60:
    alert(f"{PINNED} sunsets {sunset} — schedule the version bump")  # major bump needs a re-test

Un 404 de una versión cerrada es una caída autoinfligida. Trata el gobierno de versiones como una tarea recurrente permanente, no como un simulacro de incendio.

Ahora la ventaja — la IA entra en creatividades y feed

Con las fechas límite resueltas, el resto del año es palanca que adoptas a tu propio ritmo. Dos servicios convirtieron el trabajo de recursos y feed en algo que puedes automatizar con scripts sobre miles de SKUs:

• AssetGenerationService — Ads API, v22, beta cerrada: generación de texto e imagen con IA, con mejora y extracción de imágenes para PMax; la v23.2 añadió VideoEnhancement para vídeo generado por Google. La generación de creatividades sale de la interfaz a una capa programable.
• Product Studio — Merchant API, en alfa desde abril de 2025: títulos y descripciones de producto generados por IA, más AutomatedDiscounts para precios en tiempo real. La calidad del feed es el techo del rendimiento en Shopping y PMax, así que reescribir títulos a nivel de API significa mejorar en bloque miles de SKUs sin trabajo manual.

El pipeline concreto que esto desbloquea: lee un SKU del feed → genera un título/descripción conformes y recursos de imagen → envíalos directamente al grupo de recursos, sin paso manual en Canva por medio. Ambos servicios son pre-GA — trátalos como un piloto sobre una porción del catálogo, no como un despliegue a todo el catálogo, hasta que se gradúen.

Y la fontanería — Ads y Merchant en un mismo sitio

El cambio más infravalorado del año es poco glamuroso: las dos mitades de una cuenta de e-commerce por fin se encuentran.

Qué cambió. Desde el 22 de abril de 2026, la Merchant API es accesible desde Google Ads Scripts. Combinada con product_filters (compartición condicional de feed con Google Ads, lanzada en noviembre de 2025) y CartDataSalesView (v24), el bucle entre la salud del feed y el gasto publicitario se cierra dentro de un mismo entorno.

Por qué importa para tu cuenta. La vieja separación — campañas en Scripts, feed gestionado en otro sitio — significaba que un producto rechazado seguía quemando presupuesto hasta que un humano se daba cuenta. Ahora un solo script puede reaccionar a un rechazo de feed pausando una campaña o sacando el SKU de un grupo de listings de PMax. Y CartDataSalesView trae la segmentación de conversiones a nivel de producto a la API, así que obtienes ROAS por SKU sin coser a mano los datos de campaña al feed:

-- Product-level ROAS straight from the API (v24+), no manual feed stitching
SELECT segments.product_item_id,
       metrics.conversions_value,
       metrics.cost_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.conversions_value DESC

Esa única query es la entrada de una segmentación por rentabilidad que antes reconstruías a mano cada mes. (El recurso es cart_data_sales_view, lanzado en la v24; confirma la disponibilidad de segmentos en las notas de la versión que uses.)

El año en una sola línea de tiempo

Cada versión mayor de abajo sale de las notas de versión oficiales; los hitos de Merchant, de las últimas novedades de la Merchant API. La columna de la derecha es la única que debería gobernar tu calendario — todo lo que tiene fecha es innegociable.

[DURA 18 ago] 1. Migración de feed → fuera v2.1, a las sub-APIs de Merchant
[DURA sep]    2. Inventario de DSA → lanza primero un A/B ADOPT_AI_MAX
[CONTINUA]    3. Vigilancia de versión → avisa 60 días antes del cierre
[ventaja]     4. Pipeline de recursos → AssetGenerationService / Product Studio
[ventaja]     5. ROAS por SKU → segmentación con cart_data_sales_view
[ventaja]     6. Bucle cerrado → Merchant-en-Scripts: rechazo → pausa

FAQ