Периодические ответы 410 Gone в синхронизации товаров — не обычный сбой сети. Google завершил поддержку Content API for Shopping 18 августа 2026 года и с 1 сентября намеренно отклоняет часть запросов от проектов без действующего продления.
Не скрывайте 410 бесконечными retry. Определите, какая система отправляет данные, зарегистрируйте Google Cloud-проект, перенесите используемые вызовы на Merchant API v1, сохраните идентичность offer и проведите сверку на ограниченной группе товаров.
410 означает вывод API из эксплуатации
Официальная дата sunset Content API for Shopping — 18 августа 2026 года. С 1 сентября запросы клиентов без активного продления могут периодически завершаться HTTP 410. Ответ содержит сведения о затронутом Google Cloud-проекте и указывает на Merchant API v1. По документации Google доля отказов будет расти вплоть до полного отключения endpoint в начале 2027 года.
Это другой класс ошибки, чем 429 или временный 5xx. Для rate limit и краткого сбоя нового API уместен ограниченный exponential backoff. Но повтор запроса к выводимому сервису не устраняет причину. Более того, он может создать ложную картину: job завершился «почти успешно», хотя новые цены, остатки или удаления не дошли до Google.
Сначала оцените коммерческий ущерб. Сохраните ответ, метод, timestamp, ID Cloud-проекта, Merchant Center-аккаунт и набор затронутых offer. Отдельно посчитайте пропущенные изменения цены, availability и удаления. Сверьте последнюю принятую версию товара со страницей и checkout. Устаревшая цена в Google — уже проблема покупателя и рекламного бюджета, а не только красная строка в логе.
Установите настоящего владельца соединения
Не каждому магазину требуется собственная разработка. Google указывает, что при работе через готовую ecommerce-платформу или поставщика фида миграцией занимается технологический партнер. Но внутренний скрипт, middleware агентства, собственное приложение или SaaS, обращающийся к shoppingcontent.googleapis.com/content/v2.1, нужно переносить самостоятельно.
Не полагайтесь на название источника в интерфейсе Merchant Center. Проследите реальный путь данных:
- найдите в репозиториях, cron jobs и serverless-функциях
content/v2.1, старые библиотеки иcustombatch; - проверьте Google Cloud logs по проектам, service account и OAuth client;
- перечислите jobs для товаров, остатков, промоакций, data feed, аккаунтов и status report;
- назначьте владельца каждому credential, deployment и alert;
- попросите внешнего провайдера назвать версию API и предоставить подтверждение состоявшегося cutover.
Нужна таблица фактических методов: объем, пиковая скорость, аккаунты, используемые поля ответа и последствия отказа. Простая схема «ERP → Google» не покажет забытый ночной отчет или отдельный процесс удаления снятых с продажи товаров.
Новый API нельзя подключить заменой URL
| Content API | Merchant API v1 | Риск |
|---|---|---|
| Единый API и числовые ID | Версионируемые sub-API и resource name | Самодельный путь указывает не на тот ресурс |
products.insert | productInputs.insert с обязательным data source | Offer записан в неверный источник |
| ID с channel и двоеточиями | language~feedLabel~offerId | Теряется история или ломается encoding |
| Вход и статус в одном объекте | Записываемый ProductInput и read-only Product | Принятый input принимают за одобренный товар |
products.custombatch | Конкурентные запросы или HTTP batch | Меняется частичный отказ и расход quota |
| Цена value + currency | amountMicros + currencyCode | Ошибка единиц и округления |
Каждый Google Cloud-проект, которым приложение авторизуется в Merchant API, проходит разовую developer registration. Для production Merchant Center требуется подтвержденный сайт; identity, выполняющей регистрацию, нужен admin access. Внутренняя автоматизация может использовать service account, а приложение для чужих клиентских аккаунтов — OAuth 2.0. API key не подходит.
Полные ресурсные name лучше сохранять из ответа Google, а не собирать из чисел. Google также рекомендует один раз дополнить локальные товарные записи точным именем data source. Это снижает риск перепутать primary, supplemental, local и regional источники или некорректно закодировать offer ID.
Опишите поведение каждого вызова
Для каждого используемого метода составьте контракт: старый request, новый ресурс и метод, преобразование payload, читаемые поля response и проверяемый результат. Начните не со всех файлов сразу, а с минимального законченного сценария — записать один товар, получить обработанный результат и прочитать issues.
- Регистрация и доступ. Включите Merchant API, зарегистрируйте проект и назначьте живой контакт, который получает сервисные уведомления.
- Data source. Выберите или создайте правильный API-источник и сохраните его полное имя.
- Адаптер. Оставьте внутреннюю модель каталога стабильной; преобразуйте ее в новый payload на границе интеграции.
- Offer identity. Используйте прежний
offerIdдля того же товара или варианта, чтобы не обнулять историю. - Reconciliation. Сравнивайте input, processed Product, issues и количество позиций, а не только HTTP-ответ.
Google допускает поэтапную миграцию sub-API и одновременную работу двух интерфейсов. Но два неконтролируемых writer создают гонку. Shadow read можно использовать широко; двойную запись ограничьте тестовой группой, присвойте каждой исходной операции стабильный ID и автоматически сравнивайте критические поля.
Разделите отправленный input и результат обработки
ProductInput — данные, которые передала ваша система. Product — доступный только для чтения результат после применения правил, объединения источников и обработки Google; там же находится статус. Успешный productInputs.insert запускает обработку, но не гарантирует показ товара.
Тестовая выборка должна включать языки, feed label, страны, валюты, обычные и акционные цены, варианты, наличие, local inventory, исключенные destinations и offer ID со спецсимволами. Для каждого примера проверьте:
- правильные data source, content language, feed label и неизменный offer ID;
- конвертацию цены в micros и верный currency code;
- сохраненный resource name и корректный URL-encoding;
- совпадение критических полей в обработанном Product;
- получение item issues и account issues из новых ресурсов;
- согласованность фида со страницей товара, Product schema и checkout.
Удаление защищайте строже обновления. Перед delete получите точный Product и его data source, ограничьте размер первой группы и останавливайтесь при неоднозначном сопоставлении. Ошибочное массовое удаление из рабочего источника опаснее краткой задержки фида.
Перестройте batch, quota и обработку ошибок
У custombatch нет прямого аналога-метода. Merchant API поддерживает параллельные отдельные вызовы и multipart HTTP batching. Пакет из N операций учитывается как N запросов quota. Проектируйте частичный успех: собственный ID каталогового события должен связывать исходное изменение, попытку и повтор.
Изучите quota groups конкретного аккаунта, ограничьте concurrency и проведите нагрузочный тест с запасом. Exponential backoff с jitter используйте только для rate limit и документированных временных ошибок. Validation, authorization и другие постоянные отказы направляйте в очередь разбора, а не повторяйте бесконечно. Вместе храните HTTP status, reason, metadata, метод, время и очищенный от секретов payload.
Контролируйте три задержки: источник → принятый ProductInput, input → processed Product, processed Product → корректное коммерческое предложение. Так обнаруживается реальная потеря свежести, даже если процент успешных API-вызовов выглядит высоким.
Переключайте каталог по измеримым критериям
| Контроль | Доказательство | Стоп-сигнал |
|---|---|---|
| Идентичность | Прежние offer ID, верные name и data source | Дубликаты, исчезновение или смена владельца offer |
| Точность | Цена, наличие, URL и вариант совпадают | Значимое расхождение |
| Полнота | Каждый старый метод перенесен или отключен решением | Остались неизвестные production-вызовы |
| Надежность | Пройдены тесты quota, latency и частичного отказа | Очередь нарушает целевую свежесть |
| Коммерция | Статус, страница, schema и checkout согласованы | Падает число пригодных к показу offer |
Начните с одного Merchant Center-аккаунта или низкорисковой группы. Проследите полный цикл каталога и реальное изменение цены либо остатка. Расширяйте долю только после сверки. Затем выключите старый writer и поставьте alert на любой новый вызов Content API — забытый cron не должен продолжать создавать 410 и маскировать устаревшие данные.
Если команда объективно не успевает, Google принимает запросы на временное продление активной интеграции. Оно защищает проект от запланированной деградации только в согласованный период и не действует после окончательного отключения. Это резерв времени для миграции, а не новая постоянная дата.
Семидневный план восстановления
Недели достаточно для одного понятного товарного контура. Advanced accounts, local inventory, promotions, reports и множество клиентских аккаунтов потребуют отдельных потоков. Сначала защищайте операции, влияющие на цену и фактическую доступность товара.
Частые вопросы
Почему Content API for Shopping отвечает 410 Gone?
После sunset 18 августа Google с 1 сентября 2026 года периодически отклоняет запросы проектов без активного продления. Это плановый вывод API из эксплуатации.
Можно ли устранить 410 повторными запросами?
Нет. Доля отказов будет расти. Повторяйте только временные ошибки Merchant API, а старый вызов переносите.
Нужен ли собственный переход магазину на Shopify?
Если синхронизацией занимается готовое приложение, миграцию должен выполнить его поставщик. Проверьте фактический источник и запросите подтверждение версии. Собственные скрипты остаются вашей зоной ответственности.
Можно ли временно использовать оба API?
Да. Google поддерживает поэтапную миграцию. Shadow read безопасен; двойной write ограничивайте, чтобы источники не перехватывали один offer.
Успешный insert означает, что товар одобрен?
Нет. Он подтверждает прием input. Затем нужно прочитать обработанный Product, его статус и issues.
Источники и дата проверки
Проверено 19 сентября 2026 года по официальной документации Google: график отключения Content API, обзор перехода, миграция товаров, регистрация разработчика, отправка нескольких запросов и обработка ошибок. Сроки, quota и доступность методов меняются; перепроверьте требования перед cutover.
Rendframe может найти устаревшие вызовы, построить адаптер Merchant API, сверить каталог и добавить контроль частичных отказов. Начните с аудита фида Merchant Center, проверьте доставку Product schema или пришлите очищенный ответ 410 и название метода.