En resumen: La Content API for Shopping v2.1 se apaga el 18 de agosto de 2026. Ese día dejan de funcionar las subidas de feed, los feeds suplementarios, los custom labels, las actualizaciones de precio y stock y las comprobaciones de rechazos. La sucesora, Merchant API v1, está en GA desde julio de 2025 y es genuinamente mejor. ErrorInfo legible por máquina, paginación de 1.000 filas, patch parcial de producto. La fecha límite más dura del año.
Lo primero que hice al leer el anuncio fue abrir nuestra codebase en Lynt y buscar shoppingcontent.googleapis.com. Cada resultado es un script que muere el 18 de agosto de 2026. Ese día Google apaga la Content API for Shopping v2.1 para siempre. La intermedia Merchant API v1beta ya se apagó el 28 de febrero de 2026, y la sucesora oficial, Merchant API v1, está en GA desde julio de 2025.
Qué se rompe en realidad
Todo lo que siga hablando con la API antigua. Subidas de feed, feeds suplementarios, custom labels, actualizaciones de precio y stock, comprobaciones de rechazos. Si un script diario mantiene tus precios sincronizados, el 18 de agosto se queda mudo y el feed se va alejando de la realidad hasta que alguien nota los ingresos que faltan. He visto ese modo de fallo en cuentas reales. Lo caro nunca es la caída en sí, lo caro son las semanas en que nadie se da cuenta.
Es la fecha límite más dura del ecosistema publicitario de Google este año. Todo lo demás de la hoja de ruta puede retrasarse. Esto no.
Por qué la migración compensa de todos modos
La Merchant API no es solo un endpoint renombrado. Divide un monolito en sub-APIs específicas (datasources, products, inventories, reports, notifications) y arregla tres cosas que hacían frágil la automatización sobre v2.1:
ErrorInfolegible por máquina. Tu lógica de reintentos decide por código de error en vez de comparar strings.- Paginación subida de 250 a 1.000 filas. El mismo informe con una cuarta parte de las llamadas.
patchde producto. Actualizas un campo en vez de volver a subir el producto entero.
Cómo ejecutar la migración
Trata la reconstrucción como una ocasión de robustecer el stack, no solo de mantenerlo a flote. Mapea cada llamada antigua a su sub-API, conecta ErrorInfo a tu capa de reintentos y cambia los informes al tamaño de página mayor. Si gestionas varias cuentas, construye el conector una vez y despliégalo por todos los clientes. La estructura de sub-APIs es la misma en todas partes, así que haces el trabajo una vez y cada cuenta lo hereda.
Ejecuta la misma búsqueda que hice yo. Busca shoppingcontent.googleapis.com en tu codebase y cuenta los resultados. Cada uno de ellos tiene ya los días contados. Para ver cómo encaja la Merchant API en el resto de cambios del año, lee mi resumen del año de la API de Google.
