Якщо синхронізація товарів раптом почала час від часу отримувати 410 Gone, проблема не в нестабільному інтернеті. Google припинив підтримку Content API for Shopping 18 серпня 2026 року, а з 1 вересня навмисно відхиляє частину запитів від проєктів без чинного продовження.
Не маскуйте 410 повторними запитами. З'ясуйте, хто надсилає дані в Merchant Center, зареєструйте Google Cloud-проєкт, перенесіть лише фактично використані методи на Merchant API v1 і звірте оброблені товари до повного перемикання.
Код 410 — це сигнал міграції, а не тимчасовий збій
За офіційним графіком Google, Content API for Shopping досяг дати припинення підтримки 18 серпня. Із 1 вересня клієнти без активного продовження періодично отримують HTTP 410. У відповіді зазначено Google Cloud-проєкт, якого стосується відмова, і вимогу перейти на Merchant API v1. Частка невдалих запитів зростатиме до повного вимкнення старих endpoint на початку 2027 року.
Тому 410 не можна обробляти так само, як 429 чи тимчасовий 5xx. Exponential backoff доречний для обмеження частоти або короткого збою нового API. Повторювати запит до сервісу, який виводять з експлуатації, небезпечно: система може позначити job як «частково успішний», хоча нова ціна, залишок або видалення товару так і не потрапили до Google.
Для локалізації інциденту збережіть повну відповідь, метод, час, ID Cloud-проєкту, Merchant Center-акаунт і групу товарів. Окремо порахуйте невдалі зміни ціни, наявності та видалення. Порівняйте останню прийняту Google версію з карткою товару й checkout. Якщо Google бачить застарілу пропозицію, це вже ризик для реклами й покупця, а не лише технічна помилка в логах.
Спершу встановіть, хто надсилає товари
Користувачам готових платформ не завжди потрібно змінювати код. Google прямо пише: якщо дані передає Shopify-застосунок, фід-сервіс або інший технологічний партнер, міграцію виконує цей партнер. Власна розробка потрібна для скриптів, middleware, агентських конекторів і SaaS-продуктів, що звертаються до shoppingcontent.googleapis.com/content/v2.1.
Назва джерела даних у Merchant Center не доводить, хто володіє інтеграцією. Перевірте фактичний ланцюг:
- знайдіть у репозиторіях і scheduled jobs рядки
content/v2.1,shoppingcontent.googleapis.com, старі SDK таcustombatch; - перегляньте журнали Google Cloud за проєктом, service account і OAuth-клієнтом;
- випишіть jobs для товарів, цін, залишків, промоакцій, фідів, акаунтів та звітів про статус;
- прив'яжіть до кожного credential, деплой, відповідальну команду та бізнес-процес;
- для зовнішнього сервісу попросіть письмове підтвердження версії API й дати перемикання.
Результатом має бути реєстр методів із частотою, піковим навантаженням, залежними акаунтами й наслідком відмови. Інакше команда перенесе завантаження товарів, але забуде про нічний звіт помилок або job, що видаляє недоступні позиції.
Merchant API — не просто інший домен
| Було в Content API | Стало в Merchant API v1 | Де помиляються |
|---|---|---|
| Один великий API та числові ID | Версійні sub-API і повні resource name | Код формує неправильний шлях |
products.insert | productInputs.insert із data source | Запис іде не в те джерело |
| ID із channel і двокрапками | language~feedLabel~offerId | Ламається ідентичність або URL-encoding |
| Вхідні дані й статус в одному об'єкті | ProductInput для запису, Product для результату | HTTP 200 плутають зі схваленням товару |
products.custombatch | Паралельні запити або HTTP batch | Інша модель часткової відмови та quota |
| Ціна як value + currency | amountMicros + currencyCode | Неправильна одиниця змінює ціну |
Для Merchant API кожен Google Cloud-проєкт автентифікації треба один раз зареєструвати. У production-акаунта Merchant Center має бути підтверджений сайт, а identity для реєстрації потрібен рівень admin. Власна внутрішня система може використовувати service account; сервіс, що працює з акаунтами клієнтів, має застосовувати OAuth 2.0. API key не підтримується.
Google радить зберігати повернуті ресурсні name, а не складати їх вручну. Так само варто один раз доповнити локальні товарні записи повною назвою data source. Це захищає від плутанини між primary, supplemental, local і regional джерелами та від помилок з offer ID, де є зарезервовані символи.
Побудуйте карту поведінки, а не список файлів для переписування
Для кожного старого виклику зафіксуйте: старий метод, новий ресурс, перетворення request, поля response, які читає ваш код, і критерій приймання. Почніть із найменшого завершеного сценарію: запис одного товару, читання результату після обробки й отримання issues. Лише після цього масштабуйте.
- Доступ. Увімкніть Merchant API, зареєструйте Cloud-проєкт і перевірте, що людська контактна адреса отримує сервісні повідомлення.
- Стратегія джерел. Знайдіть або створіть потрібне API data source; збережіть його повний
name. - Адаптер. Не змінюйте внутрішню модель каталогу разом із міграцією. Окремо формуйте payload для нового API.
- Ідентичність. Для того самого SKU/варіанта залиште колишній
offerId, щоб не втратити історію. - Звірка. Перевіряйте не лише відповідь на запис, а й оброблений товар, issues та кількість позицій.
Google дозволяє переносити sub-API поетапно й деякий час використовувати обидва інтерфейси. Це не означає, що два writer можуть безконтрольно записувати той самий каталог. Shadow read безпечніший; подвійний write робіть лише для обмеженої групи, де події мають стабільний ID, а поля автоматично звіряються.
Розділіть відправлені дані та кінцевий товар
ProductInput містить те, що надіслала ваша система. Read-only ресурс Product показує результат після правил Google, об'єднання джерел і обробки; там же доступний статус. Успішний productInputs.insert означає, що input прийнято. Це не гарантує показ товару.
Складіть матрицю для мов, feed label, країн, валют, звичайних і акційних цін, доступних і відсутніх товарів, варіантів, local inventory та offer ID зі спеціальними символами. Для кожного прикладу перевірте:
- правильні data source, content language, feed label і незмінний offer ID;
- перерахунок ціни в micros без втрати копійок і з правильною валютою;
- збереження resource name та коректне кодування ідентифікатора;
- збіг критичних полів у processed Product після обробки;
- отримання item issues та account issues з нових ресурсів;
- узгодженість із посадковою сторінкою, Product schema й checkout.
Операції delete потребують жорсткішого захисту. Перед видаленням отримайте точний товар і його data source, обмежте першу групу й зупиняйте процес при неоднозначному mapping. Неправильне видалення з робочого джерела небезпечніше за коротку затримку синхронізації.
Переробіть batch, quota та обробку помилок
Прямого аналога custombatch немає. Merchant API пропонує паралельні окремі виклики або multipart HTTP batching. Пакет із N операцій усе одно споживає N запитів quota. Ураховуйте частковий успіх: кожна каталогова подія повинна мати власний ID, щоб повтор можна було пов'язати з оригіналом.
Перегляньте quota groups конкретного акаунта, обмежте concurrency і тестуйте навантаження із запасом. Exponential backoff застосовуйте лише до rate limit і тимчасових збоїв, які Google вказує як повторювані. Validation, permission та інші постійні помилки відправляйте в окрему чергу на розбір. У логах зберігайте status, reason, metadata, метод, час і очищений від секретів payload.
Головна метрика — не відсоток HTTP 200, а свіжість правди: скільки часу проходить від зміни в ERP/CMS до прийнятого input, від input до processed Product і далі до коректної пропозиції. Саме тут видно, чи встигають акційні ціни та дефіцитні залишки.
Перемикайтеся через перевірні ворота
| Контроль | Доказ | Коли зупинитися |
|---|---|---|
| Ідентичність | Ті самі offer ID, правильні data source і name | З'явилися дублікати або зниклі товари |
| Правда | Ціна, залишок, URL і варіант збігаються | Є суттєва розбіжність |
| Повнота | Кожний старий метод перенесено або офіційно вимкнено | Залишилися невідомі production-виклики |
| Надійність | Пройдено тести quota, latency й часткової відмови | Черга перевищує SLA свіжості |
| Комерція | Статус, сторінка, schema та checkout узгоджені | Падає кількість придатних пропозицій |
Почніть з одного Merchant Center-акаунта або малоризикової групи товарів. Дочекайтеся повного циклу оновлення каталогу та перевірте реальну зміну ціни чи залишку. Після повного переходу вимкніть старий writer і створіть alert на будь-який новий виклик Content API.
Якщо команда не встигає, Google дозволяє попросити тимчасове продовження для активної інтеграції. Воно лише прибирає заплановані 410 до погодженої дати й не переживе остаточного вимкнення на початку 2027 року. Використайте цей час для міграції, а не для перенесення рішення.
План відновлення на сім днів
Сім днів підходять для одного зрозумілого товарного контуру. Advanced accounts, локальні залишки, промоакції, звіти й сотні клієнтських акаунтів потребують окремих потоків. Пріоритет — шляхи, від яких залежить актуальність ціни та наявності.
Поширені запитання
Чому Content API for Shopping повертає 410 Gone?
Після sunset 18 серпня Google з 1 вересня 2026 року періодично відхиляє запити проєктів без активного продовження. Це кероване згортання сервісу.
Чи допоможе retry?
Ні. Частота 410 зростатиме. Повторюйте лише документовані тимчасові помилки Merchant API, а старий виклик переносіть.
Чи потрібна міграція магазину на Shopify?
Якщо товари передає готовий застосунок, за API відповідає його провайдер. Перевірте джерело даних і попросіть підтвердження версії. Власні скрипти й застосунки залишаються вашою відповідальністю.
Чи можна паралельно використовувати два API?
Так, поетапний перехід підтримується. Shadow read корисний; подвійний write обмежуйте, щоб два джерела не сперечалися за той самий offer.
Успішний insert означає схвалений товар?
Ні. Він підтверджує приймання input. Потрібно прочитати оброблений Product, його статус та issues.
Джерела й дата перевірки
Перевірено 19 вересня 2026 року за офіційними матеріалами Google: графік вимкнення Content API, огляд міграції, перенесення товарів, реєстрація розробника, пакетні запити та обробка помилок. Терміни, quota й доступність методів можуть змінитися; звірте документацію перед cutover.
Rendframe може знайти застарілі виклики, побудувати адаптер Merchant API, звірити каталог і додати контроль часткових відмов. Почніть з аудиту фіда Merchant Center, перевірте доставку Product schema або надішліть очищену відповідь 410 та назву методу.