Migracja z Content API do Merchant API Google nie polega na zwykłej podmianie adresu endpointu. Zmieniają się między innymi nazwy zasobów, pola, metody, sposób identyfikowania danych oraz zarządzanie źródłami danych. Dlatego sama poprawna odpowiedź API nie wystarczy, aby uznać zmianę za zakończoną.
To ważne szczególnie teraz. Content API for Shopping osiągnęło oficjalną datę sunset 18 sierpnia 2026 roku. Od 1 września 2026 roku integracje bez aktywnego przedłużenia mogą okresowo otrzymywać błąd HTTP 410 Gone, a pełne wyłączenie endpointów zaplanowano na początek 2027 roku. W tym poradniku znajdziesz praktyczny sposób na sprawdzenie integracji, przygotowanie listy funkcji, zaplanowanie zmian i przetestowanie produktów, cen oraz stanów magazynowych.
Najpierw ważna aktualizacja: co stało się z Content API
Content API nie powinno być już traktowane jako rozwiązanie, które można spokojnie pozostawić bez weryfikacji. Status usługi wpływa na każdy sklep, system lub narzędzie, które korzysta z tego interfejsu do przesyłania albo pobierania danych z Merchant Center.
Daty, które warto sprawdzić w planie migracji
Najważniejsze daty są trzy. Sunset Content API nastąpił 18 sierpnia 2026 roku. Od 1 września 2026 roku żądania z integracji bez aktywnego przedłużenia mogą okresowo kończyć się błędem HTTP 410 Gone. Pełne wyłączenie endpointów zaplanowano na początek 2027 roku, choć harmonogram może zostać zmieniony.
Nie oznacza to jednak, że sama data pozwala ocenić gotowość konkretnego sklepu. Najpierw trzeba ustalić, czy dane są wysyłane przez własny kod, platformę, system ERP, PIM, middleware albo zewnętrznego operatora.
Merchant API a Content API — najważniejsze różnice
Merchant API jest następcą Content API for Shopping, ale nie stanowi jego prostej kopii. Google nie gwarantuje pełnej kompatybilności wstecznej. Podobna funkcja może mieć inną metodę, nazwę pola, strukturę zasobu albo sposób sprawdzania wyniku.
Od jednego API do zestawu wyspecjalizowanych obszarów
Merchant API ma modularną strukturę opartą na wyspecjalizowanych sub-API. W zależności od potrzeb integracja może korzystać między innymi z obszarów Accounts, Products, Data Sources, Inventories, Promotions, Notifications, Quota i Reports.
W praktyce oznacza to konieczność przypisania obecnych funkcji do właściwych obszarów. Obsługa produktów nie powinna być analizowana tak samo jak raporty, konta czy stany magazynowe. Dla każdego wywołania warto sprawdzić metodę, zasób, pola, uprawnienia i oczekiwany rezultat.
Zmiany w identyfikatorach i zasobach
W Merchant API zasoby są identyfikowane za pomocą pełnych nazw zapisanych w polu name. Operacje na zasobach podrzędnych korzystają z pola parent. Zmieniono również format adresów żądań, który zawiera sub-API, wersję i zasób.
Programista albo dostawca integracji powinien więc porównać stary i nowy format żądań, sprawdzić identyfikatory oraz ustalić, które pola wymagają przepisania. Nie należy zakładać, że funkcja o podobnej nazwie działa w obu rozwiązaniach identycznie.
Kto powinien sprawdzić swoją integrację
Weryfikacja dotyczy każdego, kto utrzymuje własną integrację wykorzystującą Content API for Shopping. Może to być sklep internetowy, system ERP, PIM, middleware, aplikacja, agencja albo inne narzędzie wysyłające dane do Merchant Center.
Szczególnej uwagi wymagają połączenia obsługujące produkty, ceny, dostępność, stany magazynowe, źródła danych, raporty, konta, promocje lub diagnostykę. Nawet jeśli dane nadal pojawiają się w Merchant Center, nie oznacza to automatycznie, że integracja nie korzysta z Content API.
Własna integracja czy rozwiązanie dostawcy?
Najpierw ustal, jaki system faktycznie uruchamia wywołania API. Sprawdź dokumentację platformy, konfigurację sklepu, system ERP i umowy lub informacje od operatora. Jeśli synchronizację prowadzi zewnętrzny partner technologiczny, zapytaj, czy migracja jest po jego stronie, jaki zakres obejmuje oraz kto będzie monitorować problemy po zmianie.
Google wskazuje, że w przypadku niektórych partnerów migrację obsługuje dostawca. Nie zmienia to potrzeby potwierdzenia odpowiedzialności. Właściciel sklepu powinien wiedzieć, kto reaguje na błędy i kto sprawdza końcowy stan danych w Merchant Center.
Lista funkcji i danych do zinwentaryzowania
Przed zmianą kodu przygotuj prosty arkusz migracyjny. Nie musi być rozbudowany, ale powinien pokazywać pełny przepływ danych. Zacznij od spisania każdego wywołania Content API, a nie tylko najważniejszych funkcji widocznych z perspektywy sklepu.
Minimalne kolumny w arkuszu migracyjnym
Przy każdej pozycji zapisz:
- obecną metodę i zasób Content API;
- system, który uruchamia wywołanie;
- częstotliwość wykonywania;
- odpowiedni sub-API i metodę w Merchant API albo informację, że wymaga dalszej weryfikacji;
- zmiany identyfikatorów, pól, formatu żądania i uprawnień;
- dane, które trzeba sprawdzić po zapisie.
Następnie pogrupuj pozycje według obszarów: Products, Data Sources, Inventories, Reports, Accounts, Promotions oraz diagnostyka. Osobno opisz produkty, ceny, dostępność i stany magazynowe, ponieważ każdy z tych elementów może wymagać innego testu.
Źródła danych jako osobna pozycja na liście
Źródła danych wymagają szczególnej uwagi. Merchant API wymaga jawnego utworzenia źródła danych przed przesyłaniem produktów i pozwala zarządzać wieloma źródłami danych typu API. W Content API istniało automatycznie tworzone źródło Content API, dlatego dotychczasowy sposób działania może nie pasować do nowego modelu.
W arkuszu zapisz, które źródło odpowiada za produkty, ceny i dostępność. Nie usuwaj starego źródła ani produktów tylko dlatego, że nowe żądanie zakończyło się powodzeniem. Najpierw potwierdź przetworzenie danych i ich przypisanie do właściwego źródła.
Plan migracji krok po kroku
Najbezpieczniej przeprowadzać migrację etapami. Zacznij od rozpoznania wykorzystywanych funkcji, następnie przygotuj dostęp, mapowanie i testy. Dopiero po sprawdzeniu wyników zmieniaj kolejne elementy produkcyjnej integracji.
Przygotowanie dostępu i konfiguracji
Do korzystania z Merchant API trzeba połączyć konto Merchant Center z projektem Google Cloud poprzez rejestrację dewelopera. Ten krok powinien poprzedzać testowanie żądań. Wcześniej sprawdź także źródła danych i wymagane uprawnienia.
Potem wskaż sub-API potrzebne w konkretnym systemie. Nie każda integracja musi korzystać ze wszystkich obszarów Merchant API. Zakres zmian zależy od metod, pól, danych i sposobu autoryzacji używanych przez dany sklep lub operatora.
Migracja etapami
Rozpocznij od mapowania metod Content API na Merchant API. Następnie przygotuj właściwe źródło danych typu API i wprowadź zmiany w zasobach, polach, adresach żądań oraz uprawnieniach.
Testuj na ograniczonym zakresie, zachowując możliwość wycofania zmian. Oddzielnie sprawdzaj zapis, odczyt i statusy. Nie zakładaj z góry bezprzerwowego działania, identycznych wyników ani zachowania wszystkich funkcji bez weryfikacji konkretnej integracji.
Jak przetestować produkty, ceny i stany magazynowe
Test powinien obejmować cały przepływ danych, a nie tylko odpowiedź na żądanie. W Products sub-API zapis dotyczy productInput, natomiast produktem końcowym jest produkt przetworzony po zastosowaniu reguł i dodatkowych źródeł danych.
Test zapisu i produktu przetworzonego
Wykonaj test nowego produktu oraz aktualizacji istniejącego. Po wysłaniu lub zmianie productInput sprawdź odpowiedź żądania, ale nie kończ na tym kontroli. Produkt przetworzony może pojawić się dopiero po kilku minutach.
Po uwzględnieniu tego opóźnienia pobierz produkt przetworzony i porównaj go z danymi źródłowymi sklepu. Sprawdź, czy zgadzają się podstawowe informacje, cena, dostępność i stan magazynowy. Następnie skontroluj statusy oraz problemy z jakością danych.
Poprawna odpowiedź na zapis nie oznacza automatycznie, że produkt został prawidłowo przetworzony albo zatwierdzony. Właśnie dlatego test musi obejmować stan końcowy widoczny w Merchant Center.
Scenariusze cen, dostępności i błędnych danych
Przygotuj osobne przypadki testowe:
- dodanie nowego produktu;
- zmiana ceny istniejącego produktu;
- zmiana dostępności;
- zmiana ilości lub lokalnego stanu magazynowego;
- przesłanie błędnego produktu;
- usunięcie albo wycofanie produktu.
Po każdym przypadku sprawdź odpowiedź, produkt przetworzony, status i problemy jakości danych. Porównuj dane ze sklepu z tym, co zostało przetworzone w Merchant Center. Nie obiecuj konkretnego czasu propagacji, ponieważ dokumentacja wskazuje na opóźnienie typowo liczone w minutach, bez uniwersalnego czasu dla każdej operacji.
Typowe błędy i checklista przed przełączeniem produkcji
Najczęstszy błąd to potraktowanie migracji jak zmiany jednego URL-a. Ryzyko pojawia się także wtedy, gdy zespół pomija mapowanie pól, identyfikatorów, metod i źródeł danych albo uznaje udany zapis za dowód poprawnego przetworzenia produktu.
Checklista przed przełączeniem
Przed zmianą produkcyjną upewnij się, że masz:
- ustaloną osobę lub firmę odpowiedzialną za migrację;
- spis wszystkich używanych metod, zasobów i danych;
- mapowanie Content API na Merchant API;
- sprawdzone sub-API, pola, identyfikatory i uprawnienia;
- przygotowane właściwe źródła danych typu API;
- przetestowane produkty, ceny, dostępność i stany magazynowe;
- zachowaną możliwość wycofania zmian.
Co sprawdzić po przełączeniu
Po przełączeniu monitoruj nie tylko działanie kodu. Sprawdź produkty przetworzone, statusy, problemy z jakością danych, ceny, dostępność oraz stany magazynowe. Potwierdź, że dane są przypisane do właściwego źródła i że zmiany docierają do końcowego produktu w Merchant Center.
Nie usuwaj starych źródeł danych ani produktów przed potwierdzeniem efektu. Jeśli pojawią się problemy, wykorzystaj przygotowany plan wycofania zmian i ponownie porównaj dane wejściowe z końcowym stanem produktu.
Merchant API Google wymaga przede wszystkim dobrego audytu, a nie szybkiej podmiany endpointu. Najpierw ustal, kto odpowiada za integrację, spisz używane funkcje i przypisz je do odpowiednich sub-API. Potem sprawdź źródła danych, przygotuj mapowanie metod, pól i zasobów oraz wykonaj testy na ograniczonym zakresie.
Zakres zmian zależy od konkretnego sklepu, platformy, systemu lub operatora, dlatego checklista nie zastępuje analizy kodu ani dokumentacji używanej integracji. Przed przełączeniem potwierdź produkt przetworzony, statusy, ceny, dostępność i stany magazynowe, a także zachowaj możliwość wycofania zmian. Sprawdź pozostałe inspiracje i praktyczne poradniki, które pomogą Ci lepiej prowadzić marketing swojej firmy.
