Content API for Shopping : les erreurs 410 ont commencé

Les notes de version du Content API tiennent en une phrase : « Content API for Shopping was sunset on August 18, 2026 », suivie de « Starting September 1, 2026, requests will experience progressive errors » (Release Notes v2.1).

Le calendrier détaillé se trouve sur la page de dépréciation. Au 1er septembre 2026 : « Introduction of intermittent failing requests », avec la formulation précise « Requests without an active extension begin intermittently failing with HTTP 410 Gone ». L'étape suivante documentée est « Early 2027 / Decommissioning / Full shutdown. All endpoints are turned down and all requests fail » (Deprecation and sunset). Google ne donne pas de date précise pour cette coupure finale : la page écrit « Early 2027 », et ajoute sous le tableau que ce calendrier n'est pas figé : « Decommissioning timing is subject to revision based on ecosystem migration progress. Check this page regularly for updates. » (Deprecation and sunset).

Le remplaçant désigné est Merchant API, vers laquelle les pages du Content API renvoient directement, bandeau d'alerte inclus (Merchant API).

Le point opérationnel tient dans une formule de la page de sunset : « initial service degradation causes only a portion of requests to fail », la fréquence d'échec augmentant ensuite progressivement jusqu'à l'arrêt complet (Deprecation and sunset).

Pour un flux produit poussé en API, ce régime intermédiaire produit un signal faible. La synchronisation se dégrade sans s'arrêter, ce qui ne déclenche aucune alerte franche côté intégration. Un module qui réessaie en silence, un cron qui ignore les codes de retour, un log applicatif que personne ne consulte : le catalogue Merchant Center peut se désynchroniser progressivement pendant que les campagnes continuent de tourner sur des données vieillissantes.

Deux réserves à garder en tête. Google ne chiffre ni le taux d'échec initial ni la vitesse de montée en charge : la documentation parle d'une « portion » de requêtes, puis d'une fréquence croissante, sans pourcentage. Et la liste des endpoints ou des ressources touchés en premier n'est pas publiée. Le seul élément ferme porte sur la coupure intégrale au décommissionnement.

Google maintient une porte de sortie temporaire : les organisations qui ont besoin de plus de temps peuvent soumettre le « Content API extension request form », décrit sur la page d'aide de Merchant API (Get help).

Trois détails comptent au moment de le remplir :

- la demande n'est valable que si vous fournissez des identifiants de projet Google Cloud corrects : « This extension is valid only if you submit correct Google Cloud project IDs », donc des project IDs, pas des noms ni des numéros ; - la demande est approuvée dès la soumission, dès lors que les project IDs sont corrects : « Extension requests submitted through the form are approved upon submission, provided that the submitted Google Cloud project IDs are correct » ; l'email confirmant le résultat arrive « within few days » (Get help) ; - le formulaire peut être soumis plusieurs fois, et « the most recent submission determines the expiration date ».

La portée est bornée par la documentation : « Approved extensions protect your projects from scheduled error responses through your approved extension window », et « Extensions don't extend past final decommissioning in early 2027 » (Deprecation and sunset). Une extension approuvée déplace donc l'échéance à l'intérieur d'une fenêtre validée, sans dépasser le décommissionnement de début 2027. La page précise qu'une soumission reste possible même après coup : « If your expiration date has passed and you are already receiving API errors, you can still submit the form to request an extension and restore access » (Get help). En revanche, la durée maximale d'une extension accordée n'est publiée sur aucune des pages consultées, seule la borne de début 2027 est ferme.

Aucune des pages normatives ouvertes n'affirme que les campagnes Shopping ou Performance Max cessent de diffuser à cause de ces erreurs 410. Ce que Google documente porte sur l'API, ses codes de retour et son calendrier.

Le seul élément public reliant la migration à la diffusion vient de la presse. Dans un article du 20 janvier 2026 signé Anu Adegbola, Search Engine Land avertissait que les configurations Shopping et Performance Max qui s'appuient sur les feed labels pour leur structure ou leur logique d'enchères « can quietly break » si ces labels ne sont pas correctement reconfigurés pendant la migration (Google Shopping API cutoff looms, putting ad delivery at risk). Search Engine Land attribue à Google la marche à suivre : « Google recommends completing the migration well ahead of the deadline, reviewing feed labels, and validating campaign delivery after reconnecting feeds » ; cette recommandation ne figure sur aucune des pages développeurs ouvertes ici, elle est rapportée par la presse. À traiter comme une hypothèse de travail à contrôler compte par compte, issue d'une source presse antérieure de plusieurs mois au jalon du 1er septembre.

Reste ce que les pages consultées ne documentent pas. Google tranche le cas général : « If you access Merchant Center through an ecommerce platform, your platform partner manages the migration on your behalf. No action is required on your part. » (Deprecation and sunset). La page ne dit pas où en est un connecteur donné (module CMS, app, connecteur ERP, outil de gestion de flux) : cet état se vérifie auprès de l'éditeur, plateforme par plateforme. Le comportement des scripts Google Ads reposant sur l'ancienne bibliothèque Content API n'est traité par aucune page ouverte non plus.

Un point de contrôle technique, à faire compte par compte plutôt qu'en supposant que l'agence, le client ou l'éditeur s'en est occupé.

1. Identifier par quel canal le flux arrive dans Merchant Center pour chaque compte : fichier, flux planifié, ou appel API. Si c'est une intégration API, déterminer si elle utilise encore Content API v2.1 ou déjà Merchant API.

2. Regarder les journaux d'erreur côté intégration, en cherchant des réponses 410. Comme la dégradation est partielle au démarrage, un taux d'erreur non nul mais minoritaire est le symptôme attendu, pas une anomalie isolée (Deprecation and sunset).

3. Comparer la date de dernière mise à jour des produits dans Merchant Center avec la fréquence théorique de synchronisation. Un écart croissant sur les prix ou les disponibilités est le premier signe exploitable dans l'interface.

4. Si la migration ne peut pas être bouclée à court terme, préparer la demande d'extension avec les project IDs Google Cloud exacts, et noter que la dernière soumission écrase la précédente pour la date d'expiration (Get help).

5. Après toute reconnexion de flux, vérifier les feed labels et contrôler que les campagnes Shopping et Performance Max concernées diffusent bien, comme le rapporte Search Engine Land, qui attribue cette recommandation à Google.