Content API Shopping arrêtée : votre flux produit doit-il migrer vers Merchant API ?
Votre catalogue peut continuer à fonctionner, afficher des erreurs 410 ou dépendre d’un prestataire déjà en migration : voici comment identifier votre situation.
La Content API for Shopping a atteint sa date de sunset le 18 août 2026. Depuis le 1er septembre, Google applique une dégradation progressive : les requêtes envoyées par des clients sans prolongation active peuvent échouer de manière intermittente avec le code HTTP 410 Gone. Si votre boutique, votre plugin, votre PIM, votre ERP ou votre agence utilise encore cette API, votre catalogue doit passer vers Merchant API.
Cette migration ne concerne pas mécaniquement tous les marchands. Un flux importé dans Merchant Center depuis un fichier, un autofeed ou Google Sheets ne fonctionne pas comme une intégration qui crée et met à jour les produits par API. La première étape consiste donc à identifier le canal qui transmet réellement vos données produit.
Les dates à connaître pour Content API et Merchant API
Google a annoncé la transition vers Merchant API lors du lancement général de cette nouvelle API en août 2025. La Content API for Shopping a ensuite atteint son sunset le 18 août 2026. Depuis le 1er septembre 2026, Google provoque des échecs intermittents sur les requêtes des clients sans prolongation active afin d’encourager la migration avant le retrait complet.
CHIFFRES CLÉS
Trois repères pour votre migration
Ces dates concernent les intégrations programmatiques à Merchant Center. Elles ne permettent pas à elles seules d’identifier votre mode de transmission.
18 août 2026
Date de sunset officielle de la Content API for Shopping.
Source : Google Developers, 2026
1er septembre 2026
Début des erreurs intermittentes HTTP 410 Gone pour les clients sans prolongation active.
Source : Google Developers, 2026
Début 2027
Période annoncée pour le retrait complet des endpoints après la phase de dégradation progressive.
Source : Google Developers, 2026
Une intégration peut continuer à répondre à certaines requêtes puis échouer sur d’autres. Cette situation rend le problème plus difficile à repérer qu’une coupure totale. Votre tableau de bord e-commerce peut sembler normal alors que certaines mises à jour de stock, de prix ou de nouveaux produits ne remontent plus correctement.
Mon flux produit est-il concerné ?
Vous devez d’abord identifier le chemin suivi par vos données. Les noms commerciaux des plugins et des agences ne suffisent pas : un même outil peut utiliser un fichier, un flux Google Sheets, une API ancienne ou Merchant API selon sa version et sa configuration.
CAS 1
Fichier importé dans Merchant Center
Vous envoyez un fichier XML, CSV, TSV ou similaire. Votre situation dépend de la source réellement configurée et de la manière dont elle est actualisée.
Contrôle : Vérifiez dans Merchant Center si la source apparaît comme un fichier, un import programmé ou une source créée dans l’interface.
CAS 2
Google Sheets
Google documente les sources de type GOOGLE_SHEETS. Elles peuvent apparaître dans la liste des sources de données en tant que sources gérées par l’interface.
Contrôle : Vérifiez le type de source de données et l’URL de récupération dans Merchant Center.
CAS 3
Plugin ou connecteur e-commerce
WooCommerce, Shopify, PrestaShop, Magento, un PIM ou un outil de feed peuvent masquer l’usage de Content API derrière une interface simple.
Contrôle : Demandez le nom du module, sa version, son éditeur et le statut officiel de sa migration Merchant API.
CAS 4
Développement ou middleware sur mesure
Une application interne, un connecteur ERP, un script ou une plateforme d’intégration pousse directement les données vers Google par API.
Contrôle : Recherchez les domaines shoppingcontent.googleapis.com, les appels v2.1 et les méthodes customBatch.
Le diagnostic à effectuer dans Merchant Center
Un administrateur Merchant Center ou votre prestataire peut consulter les sources configurées dans le compte. Google documente la méthode dataSources.list dans Merchant API pour lister les sources. Les résultats peuvent inclure des sources créées depuis l’interface Merchant Center, des autofeeds et des sources Google Sheets, qui sont accessibles en lecture via l’API.
Vous n’avez pas besoin d’exécuter cette requête vous-même pour avancer. Demandez simplement une capture, un export ou une liste des sources actives avec ces informations :
- Nom de la source et type de source.
- Compte Merchant Center concerné.
- Outil qui alimente cette source.
- Fréquence de mise à jour.
- Nombre de produits envoyés.
- Dernière actualisation réussie.
- Responsable technique ou prestataire.
- Présence éventuelle de messages Content API, d’erreurs 410 ou d’une extension active.
Les fichiers et Google Sheets restent-ils utilisables ?
Google distingue les sources de données gérées dans Merchant Center des appels réalisés par l’ancienne Content API. La documentation Merchant API indique que les sources créées avec Content API restent compatibles avec Merchant API. Elle indique aussi que la liste des sources peut inclure des sources créées via l’interface Merchant Center, des autofeeds ou Google Sheets.
Google précise qu’une source GOOGLE_SHEETS récupère le fichier depuis le tableur indiqué par son URL de récupération. La création de ce type de source ne s’effectue pas via Merchant API : elle se réalise depuis Merchant Center. Ces éléments confirment qu’un flux Google Sheets relève d’un mécanisme distinct de l’envoi direct de produits par Content API.
Cette distinction ne dispense pas d’un contrôle. Votre agence peut utiliser Google Sheets pour une partie du catalogue et Content API pour les mises à jour rapides de prix, de stock, de promotions ou de diagnostics. Le bon diagnostic porte donc sur chaque fonction assurée par votre système.
Un fichier Google Sheets récupéré par Merchant Center constitue une source de données distincte dans la configuration du compte. Une intégration qui appelle directement les endpoints Content API relève d’un autre chemin technique.
Une boutique peut combiner plusieurs chemins : un fichier pour les produits principaux, une API pour les mises à jour de stock et un plugin pour les promotions. Demandez une cartographie fonction par fonction avant de conclure que votre catalogue est protégé ou exposé.
Ce qui change lors d’une migration vers Merchant API
Merchant API ne reprend pas à l’identique les URLs, les identifiants et les méthodes de Content API. Ce point explique pourquoi une simple modification de domaine ne suffit pas pour un développement sur mesure. Google recommande d’utiliser la valeur du champ name renvoyée par l’API plutôt que de construire manuellement les noms de ressources.
Principales différences documentées entre Content API for Shopping et Merchant API
| Élément | Content API for Shopping | Merchant API | Conséquence pour votre intégration |
|---|---|---|---|
| Format d’URL | shoppingcontent.googleapis.com/content/v2.1/... | merchantapi.googleapis.com/{SUB_API}/{VERSION}/{RESOURCE_NAME}:{METHOD} | Les routes changent. Les appels existants doivent être réécrits et testés. |
| Nom des ressources | Identifiants séparés utilisés dans les chemins et paramètres. | Noms de ressources structurés tels que accounts/{account}/products/{product}. | Le code doit récupérer et utiliser les nouveaux noms de ressources. |
| Identifiant produit | Format historique incluant notamment des séparateurs par deux-points. | Format contentLanguage~feedLabel~offerId dans la ressource produit. | Les règles de transformation et les systèmes qui stockent l’ancien identifiant doivent être revus. |
| Envois groupés | customBatch disponible pour plusieurs méthodes. | customBatch absent pour les produits et les sources de données. | Google documente des appels asynchrones, du HTTP batching ou des appels individuels selon la ressource. |
| Prix produit | Montant représenté notamment avec value sous forme de chaîne et currency. | Montant représenté avec amountMicros et currencyCode. | Les transformations de prix, les validations et les tests de précision monétaire doivent être revus. |
| Sources de données | datafeeds et datafeedstatuses. | dataSources, opérations de récupération et informations de téléversement. | Les outils qui créent, actualisent ou contrôlent un flux doivent adapter leurs appels. |
Les changements techniques ne concernent pas uniquement le développeur. Un prix mal converti, un stock qui ne remonte plus ou une source mal associée peut produire des refus, des écarts de disponibilité ou une baisse de diffusion dans vos campagnes. Prévoyez une recette métier après chaque adaptation.
Le message à envoyer à votre prestataire
Copiez ce message dans un e-mail, un ticket de support ou votre outil de gestion de projet. Il vise à obtenir un diagnostic précis sans exiger de vous une expertise API.
MESSAGE À ENVOYER
Vérifier notre exposition à la fin de Content API
Objectif : Obtenir un état des lieux documenté sur le canal qui transmet notre catalogue à Google Merchant Center et sur le statut de migration vers Merchant API.
Bonjour, Google a arrêté la Content API for Shopping le 18 août 2026. Depuis le 1er septembre, des requêtes sans prolongation active peuvent recevoir des erreurs HTTP 410 intermittentes. Pouvez-vous nous confirmer, pour notre compte Merchant Center : 1. Les sources de données actives et leur type : fichier, Google Sheets, autofeed, plugin, PIM, ERP, middleware ou API sur mesure. 2. Les fonctions qui utilisent encore Content API for Shopping : produits, prix, stock, promotions, commandes, diagnostics, sources de données ou autres. 3. La version exacte du plugin, connecteur ou composant concerné. 4. Le statut de migration vers Merchant API : terminé, en test, planifié ou non prévu. 5. La date de bascule prévue et le responsable technique. 6. Les changements attendus sur les prix, stocks, produits, promotions, diagnostics et alertes. 7. La procédure de recette et les contrôles qui confirmeront que le catalogue fonctionne après migration. 8. Les éventuelles erreurs HTTP 410 déjà observées, avec leurs dates et leurs impacts. Merci de joindre une capture ou une liste des sources de données actives dans Merchant Center et de préciser les actions attendues de notre part.
À vérifier : Demandez une réponse écrite mentionnant le compte Merchant Center, les sources concernées, le connecteur ou le code utilisé, le calendrier de migration, les risques identifiés et le plan de recette.
Recette de migration : ce qu’un e-commerçant doit vérifier
Une migration est terminée lorsque le catalogue fonctionne dans les conditions qui comptent pour votre activité. Le statut « code déployé » ne garantit pas que les prix, stocks, attributs et diagnostics attendus remontent correctement dans Merchant Center.
Contrôler votre catalogue après une migration Merchant API
Effectuez ces vérifications avec votre prestataire sur un périmètre de produits représentatif avant de considérer la migration comme finalisée.
-
Choisir un échantillon de produits représentatif
Sélectionnez des références qui couvrent les situations fréquentes de votre catalogue. Ajoutez au moins un produit récemment modifié afin de vérifier la vitesse de remontée des changements.
Point de contrôle : L’échantillon inclut des produits en stock, hors stock, en promotion, avec variantes et avec attributs obligatoires pour votre secteur.
-
Comparer les prix, stocks et identifiants
Vérifiez le prix, le prix promotionnel lorsqu’il existe, la devise, la disponibilité, l’identifiant article, le titre, le lien produit, l’image principale et les attributs spécifiques à votre catalogue.
Point de contrôle : Les valeurs présentes dans votre boutique, votre source de données et Merchant Center correspondent après la synchronisation.
-
Contrôler les diagnostics et les erreurs
Consultez les diagnostics Merchant Center après les mises à jour. Demandez à votre prestataire où apparaissent les erreurs API, comment elles sont journalisées et quelle alerte prévient l’équipe lorsqu’une synchronisation échoue.
Point de contrôle : Les erreurs de synchronisation, produits refusés et avertissements sont vus par une personne responsable avec une procédure de correction.
-
Tester une modification réelle
Modifiez une donnée sur un produit de test selon votre procédure habituelle. Mesurez le délai de propagation. Vérifiez que la valeur finale correspond à votre boutique et qu’aucun format de prix ou identifiant ne s’est dégradé pendant la migration.
Point de contrôle : Une modification de prix ou de stock remonte dans le délai attendu et conserve la bonne valeur dans Merchant Center.
-
Documenter le résultat et le plan de support
Gardez les preuves de recette, le nom du connecteur, sa version, les accès administratifs, les règles de planification et le canal de support. Cette documentation réduira le temps de diagnostic lors d’une future évolution du catalogue ou de l’API.
Point de contrôle : Le responsable métier conserve les accès, les contacts, les captures de recette et la procédure d’incident.
Exemple illustratif : une boutique avec plugin et PIM
EXEMPLE ILLUSTRATIF
Deux flux, deux responsabilités techniques
LE CONTEXTE
Une boutique vend plusieurs milliers de références. Son agence a configuré un plugin e-commerce pour envoyer les produits vers Merchant Center. Son PIM met aussi à jour les prix et le stock plusieurs fois par jour.
LE DÉROULÉ
La responsable e-commerce ouvre Merchant Center et voit une source de données active. Elle suppose que le plugin gère tout le catalogue. L’agence confirme ensuite que le plugin alimente les titres, images et descriptions alors que le PIM pousse les mises à jour de prix et de stock par une intégration différente.
Le PIM appelle encore une méthode de Content API. À partir du 1er septembre, certaines mises à jour de stock retournent une erreur 410. Les produits restent visibles dans Merchant Center, mais certaines disponibilités deviennent obsolètes. La boutique lance une migration Merchant API pour le PIM puis exécute une recette sur des produits avec stock faible, rupture, promotion et variantes.
Cette mise en situation montre pourquoi le diagnostic doit porter sur les flux réels et non sur le seul nom d’un plugin ou l’apparence d’un catalogue dans Merchant Center.
CE QUE CET EXEMPLE MONTRE
La présence d’un flux qui semble fonctionner ne prouve pas que toutes les données utilisent le même canal. Une migration doit couvrir chaque fonction : produits, prix, stock, promotions, diagnostics et sources de données.
FAQ sur la migration Merchant API
FAQ
Questions fréquentes sur la fin de Content API
Ces réponses résument les points de contrôle les plus utiles pour un e-commerçant. La configuration exacte dépend de votre compte Merchant Center, de vos sources de données et de vos prestataires.
Oui. Google indique que la Content API for Shopping a atteint sa date de sunset le 18 août 2026. Depuis le 1er septembre 2026, les requêtes envoyées par des clients sans prolongation active peuvent échouer de manière intermittente avec un code HTTP 410 Gone.
Google documente les sources de données Google Sheets dans Merchant API et précise qu’elles peuvent être créées depuis Merchant Center. Un flux Google Sheets constitue un canal distinct des appels directs à Content API. Vérifiez toutefois si une autre partie de votre système utilise encore l’ancienne API pour les stocks, prix, promotions ou diagnostics.
La réponse dépend de l’éditeur, de la version installée et de la configuration de votre compte. Demandez à votre prestataire si le plugin appelle encore les domaines Content API historiques, s’il utilise Merchant API et quelle version est nécessaire pour la migration.
Le code HTTP 410 indique que la ressource demandée n’est plus disponible. Dans le calendrier de Google, il apparaît depuis le 1er septembre 2026 de manière intermittente sur les requêtes Content API des clients sans prolongation active. Conservez le message complet d’erreur et transmettez-le à votre intégrateur.
Merchant API emploie une architecture de ressources différente. Google indique un format d’URL basé sur une sous-API, une version, un nom de ressource et une méthode. Les produits utilisent aussi un format de nom de ressource différent. Les intégrations sur mesure doivent adapter ces éléments, puis les tester.
La réponse dépend de votre canal de données. Google indique que les sources créées avec Content API restent compatibles avec Merchant API. Les intégrations qui créent ou mettent à jour les données par API doivent en revanche migrer leurs appels et contrôler les résultats. Votre prestataire doit préciser les opérations concernées dans votre configuration.
Ce que vous pouvez faire aujourd’hui
Demandez la liste des sources de données actives dans votre Merchant Center et envoyez le message de diagnostic à votre agence, votre éditeur de plugin ou votre intégrateur. Cherchez une réponse documentée sur le canal utilisé pour les produits, les prix, les stocks, les promotions et les diagnostics.
Si une partie du catalogue utilise encore Content API, planifiez une migration Merchant API et une recette métier. Le contrôle final doit vérifier les produits visibles, les valeurs de prix, les disponibilités, les erreurs, les délais de synchronisation et les personnes capables d’intervenir. Cette démarche protège la continuité de vos campagnes Google Shopping et la fiabilité des informations affichées aux acheteurs.
Préparer votre catalogue pour Google AI Mode et Gemini
SOURCES
Sources consultées
Ces documents Google ont été consultés le 19 septembre 2026 pour vérifier le calendrier de retrait, les erreurs progressives et les changements de migration vers Merchant API.
- Google Developers — Content API for Shopping: Deprecation and sunset
Calendrier officiel du sunset, erreurs HTTP 410 intermittentes à partir du 1er septembre 2026 et dégradation progressive.
- Google Developers — Migrate from Content API for Shopping to Merchant API
Architecture des URLs, noms de ressources et principes généraux de compatibilité.
- Google Developers — Migrate products
Différences documentées sur les produits, les identifiants et la disparition de customBatch.
- Google Developers — Migrate data sources
Compatibilité des sources existantes, changements sur les data sources et opérations de récupération.
- Google Developers — View your data source configurations
Types de sources visibles, dont les sources créées dans Merchant Center, les autofeeds et Google Sheets.
