En bref: La Content API for Shopping v2.1 ferme le 18 août 2026. Ce jour-là, les imports de flux, flux supplémentaires, custom labels, mises à jour de prix et de stock et contrôles de refus cessent de fonctionner — une coupure nette, pas une option de confort. Sa remplaçante, la Merchant API v1, est en GA depuis juillet 2025 et vraiment meilleure : ErrorInfo lisible par la machine, pagination à 1 000 lignes et patch produit partiel. C'est l'échéance la plus dure de l'année.
Notez bien la date : 18 août 2026. C’est le jour où Google ferme définitivement la Content API for Shopping v2.1. La Merchant API v1beta intermédiaire a déjà fermé le 28 février 2026, et la Merchant API v1 est en GA — la remplaçante officielle — depuis juillet 2025.
Ce qui casse vraiment
Tout ce qui dialogue encore avec l’ancienne API cesse de fonctionner ce jour-là : imports de flux, flux supplémentaires, custom labels, mises à jour de prix et de stock, contrôles de refus. Pour un compte e-commerce dont l’automatisation de flux repose sur des scripts, ce n’est pas un « bon à migrer » — c’est une coupure nette. Vous la ratez, votre flux s’éteint.
C’est l’échéance la plus dure de tout l’écosystème publicitaire de Google cette année. Tout le reste de la feuille de route peut glisser. Pas celle-ci.
Pourquoi la migration vaut le coup de toute façon
La Merchant API n’est pas un simple endpoint rebaptisé. Elle scinde une surface monolithique en sous-API ciblées — datasources, products, inventories, reports, notifications — et apporte des améliorations qui rendent l’automatisation plus robuste :
ErrorInfolisible par la machine — une vraie logique de retry au lieu de parser des messages d’erreur en chaîne.- Pagination passée de 250 à 1 000 lignes — moins d’appels pour le même rapport.
patchproduit — des mises à jour partielles au lieu de renvoyer le produit entier.
Comment automatiser la transition
Traitez la refonte comme une occasion de durcir la stack, pas seulement d’assurer le service minimum. Reliez chaque ancien appel à sa sous-API d’accueil, branchez ErrorInfo dans votre couche de retry, et basculez les rapports sur la pagination élargie. Si vous gérez plusieurs comptes, construisez la migration une seule fois sous forme de connecteur partagé et déployez-la sur l’ensemble des clients — la structure en sous-API est cohérente, donc le travail s’amortit.
L’horloge est la seule raison de l’urgence. La destination est franchement meilleure que le point de départ. Pour la vue d’ensemble de la place de la Merchant API dans le reste des changements de l’année, consultez notre bilan de l’année de l’API Google.