En resumen: Quedan cuatro semanas. La Content API for Shopping v2.1 se apaga el 18 de agosto de 2026 y no habrá prórroga. Este es el plan de cuenta atrás para el tiempo que queda. Un grep que encuentra cada integración que va a morir, primero migras las rutas del dinero, después las de lectura, y al final un funcionamiento en paralelo para apagar la API vieja tú mismo antes de que Google lo haga por ti.
Esta mañana ha saltado el recordatorio. Lo puse en junio, el día que escribí sobre el cierre de la Content API, y lo coloqué exactamente cuatro semanas antes de la fecha límite. El 18 de agosto de 2026 Google apaga la Content API for Shopping v2.1 para siempre. Cuatro semanas dan para migrar con calma. También dan para convencerte de que lo harás la semana que viene, cuatro veces seguidas.
Ya expliqué qué se rompe y por qué la Merchant API es mejor herramienta en el artículo de junio. No lo voy a repetir. Este es el plan que sigo cuando se acerca una fecha límite dura. Una semana por fase.
Esta semana, encuentra todo lo que va a morir
No puedes migrar lo que no has encontrado. Ejecuta esto sobre cada repo que toque Merchant Center:
grep -rEn \
"shoppingcontent\.googleapis\.com|ShoppingContent|content/v2(\.1)?([^[:alnum:]_.-]|$)|[\"']content[\"'][,[:space:]]+[\"']v2(\.1)?[\"']|\.content\([\"']v2(\.1)?[\"']" .El primer patrón caza las llamadas REST directas. Los demás cazan las librerías cliente oficiales, porque te esconden la URL. Python construye el cliente condenado con build('content', 'v2.1'), PHP lo llama Google_Service_ShoppingContent, Node usa google.content('v2.1') y los proyectos de Apps Script cargan un servicio avanzado de ShoppingContent que nunca aparece en ningún repo. Revisa tus proyectos de scripts a mano.
Luego pon cada resultado en una hoja con cuatro columnas. Qué hace, cada cuánto se ejecuta, quién es el dueño y cuánto tardará alguien en darse cuenta cuando muera en silencio. Por esa última columna es por la que ordenas.
Tu grep solo cubre el código que escribiste tú. Los escenarios de Zapier, las herramientas de feeds, los repricers y los conectores también pueden estar sobre la API vieja. Escribe esta semana a cada proveedor y pídele su fecha de Merchant API por escrito. Su fecha límite de migración es tu caída.
Semana dos, migra las rutas del dinero
Empieza donde el silencio cuesta ingresos. Actualizaciones de precios, de stock y subidas de feeds. En la Merchant API v1, GA desde julio de 2025, viven en las sub-APIs products, inventories y datasources, y la guía de compatibilidad mapea las llamadas viejas a sus nuevos destinos.
Una cosa me sorprendió para bien cuando en Lynt apuntamos nuestras propias herramientas a los endpoints nuevos. El token OAuth existente con el viejo scope content funcionó sin más. Las credenciales se heredan, el código no. Reescribes las llamadas y te ahorras un nuevo baile de autorización con cada cliente.
Semana tres, las rutas de lectura
Las comprobaciones de rechazos y el reporting van después. Esta también es la semana en que la migración empieza a devolverte la inversión. Los informes paginan a 1.000 filas en vez de 250, así que el mismo trabajo termina con la cuarta parte de las llamadas. Y donde tu código viejo consultaba estados de producto según un horario, la sub-API notifications te empuja los cambios.
Semana cuatro, apágala tú mismo
Deja las dos pipelines corriendo en paralelo y compara las salidas unos días. Después apaga la integración vieja una semana antes, a propósito, mientras la v2.1 todavía responde. Si algo que se te pasó depende de ella en secreto, aflora cuando aún puedes reactivar las llamadas viejas un día y arreglarlo bien.
Después del 18 de agosto no hay marcha atrás. Google acciona el interruptor para todos a la vez, y lo que el grep no encontró muere en producción.
Doce años con la Google Ads API me enseñaron que las fechas límite duras son raras. Google normalmente prorroga, mantiene lo viejo, aplaza. Esta no. Así que ejecuta el grep antes de cerrar esta pestaña. El número que imprime es la única estimación de migración que necesitas.
