Merchant API : migrer sans déplacer les offres

Une intégration catalogue encore fondée sur Content API for Shopping mérite une revue immédiate avant Q4. Google indique un sunset au 18 août 2026, des erreurs 410 intermittentes depuis le 1er septembre sans extension active, puis une extinction complète prévue début 2027, avec calendrier révisable. Il serait donc inexact de déclarer que tous les endpoints sont déjà coupés. Calendrier Google

Le travail utile consiste à identifier les appels concernés, préserver l’identité des offres et vérifier les produits traités après migration. Une réponse HTTP correcte ne prouve ni disponibilité dans les listings ni vente supplémentaire.

Identifier qui gère réellement l’intégration

Commencez par un inventaire : connecteur ecommerce, application de flux, scripts internes, jobs planifiés et opérations manuelles. Pour chaque chemin, nommez le responsable, le compte marchand, le projet d’authentification, les méthodes appelées et la source de données utilisée. Ne partagez pas les jetons ou secrets dans ce document.

Google distingue les intégrations personnalisées des plateformes tierces, dont le partenaire gère la migration. Périmètre du sunset Un marchand utilisant un connecteur géré doit demander son état de compatibilité plutôt que créer une seconde chaîne d’envoi en parallèle. Un développeur responsable d’appels directs doit examiner son propre client.

Pour un incident 410, conserver le code, l’horodatage et les métadonnées non sensibles disponibles. Vérifiez l’endpoint réellement appelé. Un échec de l’API legacy ne signifie pas que la page produit renvoie 410 au visiteur ; ce sont deux systèmes différents. Un retry peut masquer temporairement le problème et compliquer le diagnostic.

Séparer l’entrée envoyée du produit traité

Merchant API distingue ProductInput, destiné aux données envoyées, et Product, qui représente leur résultat traité. Une écriture doit préciser la source concernée. Migration produits

Concevez donc deux étapes de validation : la transformation de vos données locales, puis le contrôle du résultat disponible chez Google. La première vérifie que votre programme a produit les bons champs. La seconde vérifie ce qui reste après traitement et règles de sources. Fusionner les deux ferait apparaître un envoi accepté comme une offre déjà correctement distribuée.

Dans votre journal interne, séparez « préparé », « envoyé », « accepté techniquement », « relu après traitement » et « statut de destination contrôlé ». Ces libellés constituent une proposition de suivi, pas de nouveaux statuts officiels de l’API. Ils rendent visible l’étape qui manque lorsque l’équipe commerciale demande si une promotion peut commencer.

Cartographier les sources avant toute écriture

Merchant API utilise des sources API explicites ; leurs identifiants doivent être retrouvés et associés à votre intégration. Migration des sources

Notre procédure proposée commence par une lecture de l’inventaire autorisé. Construisez un registre reliant l’offre à sa source actuelle, aux règles pertinentes et au propriétaire opérationnel. Faites relire les écarts avant d’introduire une nouvelle source.

Google documente l’« offer stealing » : insérer une offre existante dans une autre source primaire peut la déplacer et changer les règles qui lui sont appliquées. Avertissement de migration Une duplication apparente n’est donc pas un test sans conséquence.

Pour comparer deux transformateurs, utilisez d’abord un mode local sans envoi. Le transformateur candidat produit un fichier de différences ; l’ancien reste l’unique chemin d’écriture tant que la bascule n’est pas autorisée. Signaler une différence n’exige pas de modifier une offre en production.

Préserver les identifiants et les variantes de marché

La référence impose offerId, contentLanguage et feedLabel. Elle décrit aussi les noms encodés en base64url sans padding, recommandés notamment pour les caractères spéciaux. Référence ProductInput

Évitez de reconstruire une URL avec un simple remplacement des deux-points. Stockez les noms retournés par l’API, dont les formes encodées lorsque nécessaires, et vérifiez qu’ils correspondent à la bonne offre. Ajoutez au test un SKU contenant une barre oblique pour découvrir une hypothèse d’encodage trop simple.

Pour les audiences US et UK, une langue anglaise commune n’implique pas une même devise, une même livraison ou une même source. Le ciblage dépend également des paramètres de source et des attributs produit ; une étiquette de flux n’est pas une politique de livraison. Gestion et ciblage des produits

Séparez donc l’identité technique de l’offre, le pays servi et les faits commerciaux affichés. Ce contrôle protège aussi le lecteur humain, qui doit retrouver sur la page d’arrivée le prix et la promesse correspondant à sa sélection.

Exemple de registre Q4, sans appel API

Voici deux offres entièrement fictives dans un registre interne. Les alias de source ci-dessous ne sont pas des identifiants directement utilisables dans une requête.

Le scénario d’acceptation impose que chaque ligne reste associée à sa source réelle vérifiée. Si le transformateur UK réutilise le prix USD ou l’alias américain, le test local doit échouer avant envoi. Ces prix n’expriment aucun cours de change ou tarif réellement pratiqué.

Contrôlez ensuite les champs visibles : titre, lien produit, disponibilité et devise. Une règle supplémentaire doit détecter une offre dont le prix promotionnel n’est pas prêt sur la page. Cette vérification est une proposition de contrôle commercial, distincte d’une garantie d’approbation Merchant Center.

Organiser une bascule limitée et observable

La documentation de gestion précise que les écritures concernent les sources API et que le résultat produit doit être consulté séparément. Guide de gestion Préparez une petite sélection représentative avant de traiter le catalogue entier : offre simple, variante, caractère spécial et contexte international.

Fixez un responsable de bascule, une fenêtre adaptée et une règle d’arrêt. Après chaque opération autorisée, rapprochez l’offre attendue, la source utilisée et le résultat relu. Un délai de traitement doit rester un état d’attente, jamais une validation improvisée.

La référence limite versionNumber aux insertions dans des sources primaires ; ce champ ne constitue pas une protection universelle pour PATCH. Portée de versionNumber Si plusieurs producteurs mettent à jour les mêmes offres, définissez d’abord leur responsabilité et leur ordre de traitement. Un champ mal appliqué ne corrige pas une architecture d’écriture concurrente.

Définir les preuves nécessaires avant la promotion

Notre grille d’acceptation requiert :

• le responsable de chaque connecteur identifié et son état de migration consigné ;
• les clés d’offre et sources rapprochées sans déplacement involontaire ;
• les cas d’encodage vérifiés sur des fixtures ;
• les prix, devises et disponibilités concordants après traitement ;
• les diagnostics de destination examinés, séparément des réponses HTTP ;
• une procédure de suspension de l’écriture défectueuse documentée.

Cette grille n’a pas été exécutée sur un compte marchand pendant cette recherche. Aucun taux de réussite ou délai garanti n’est avancé. Les fixtures locales démontrent au mieux la cohérence du transformateur, pas l’éligibilité d’un vrai produit.

Suivez ensuite erreurs par méthode, ancienneté des offres non rapprochées et écarts source/produit. Le registre gratuit de campagnes peut accueillir ces tâches. L’objectif Q4 est une information produit fiable ; visibilité, clics et commandes exigent leurs propres observations.