Переход Google Merchant Center с Content API на Merchant API
Переход Google Merchant Center с Content API на Merchant API восстанавливает программное управление товарами после закрытия Content API for Shopping 18 августа 2026 года. Merchant API использует endpoint merchantapi.googleapis.com и разделён на самостоятельные API для аккаунтов, товаров, источников, остатков и отчётов.
Перед первым рабочим запросом Google Cloud project связывается с основным Merchant Center аккаунтом через developer registration. В товарном контуре ProductInput принимает данные продавца, а read-only ресурс Product показывает итог после обработки Google вместе со статусами и замечаниями. Операция записи требует явного dataSource; правильный выбор источника сохраняет историю offerId и правила каталога.
Идентификатор превращается в resource name вида accounts/{account}/products/{product}, а составная часть товара использует разделитель ~ либо безопасное base64url-кодирование. Служба productstatuses объединена с Product, custombatch заменяется асинхронными запросами либо HTTP batching, а статус файлового источника читается через fileUploads.
Мы переносим только фактически используемые контуры и сохраняем связь с внутренним SKU, языком, feed label и Merchant Center аккаунтом. После переключения магазин снова обновляет каталог и остатки, получает замечания обработки и видит результат каждого запуска в техническом журнале.
Когда стоит обратиться
Обычно к нам обращаются в таких ситуациях:
- В коде используется shoppingcontent.googleapis.com, библиотека Content API v2.1 или ресурс productstatuses.
- После 18 августа 2026 года товары, цены либо остатки перестали обновляться из CMS, PIM или ERP.
- Пробный клиент Merchant API создаёт дубли, меняет источник товара или теряет связь с прежним offerId.
- Интеграция управляет несколькими аккаунтами, языками, feed label, локальными остатками либо отчётами Merchant Center.
Что именно мы сделаем
Собираем карту методов Content API, аккаунтов Merchant Center, источников товаров, расписаний и внутренних идентификаторов.
Регистрируем Google Cloud project для Merchant API и проверяем OAuth 2.0 либо сервисный аккаунт в рабочем контуре.
Переносим товары, data sources, остатки и выбранные отчёты на актуальные sub-API и resource names.
Запускаем контрольный каталог, сравниваем ProductInput, обработанный Product, статусы, цены и остатки в Merchant Center.
Переключаем расписание и передаём карту методов, идентификаторов, источников и порядок разбора ошибок.
Что входит в стоимость
79 900 ₽ за всю работу
Инвентаризируем вызовы Content API, Merchant Center аккаунты, источники и расписания, затем переносим выбранные контуры Accounts, Products, Data Sources, Inventories и Reports. Настраиваем developer registration, авторизацию, новые имена ресурсов, ProductInput, обработанный Product, dataSource и пакетную отправку. Сверяем контрольный каталог, статусы, остатки и отчёты, включаем Merchant API в рабочем расписании и передаём карту миграции.
Что будет готово
Передадим вам
- Рабочий клиент Merchant API для выбранных аккаунтов, товаров, источников, остатков и отчётов.
- Карта Content API и Merchant API с методами, полями, resource names и правилами выбора dataSource.
- Журнал обработки каталога с внутренним SKU, offerId, аккаунтом, источником и замечаниями Google.
- Протокол контрольных товаров и инструкция запуска, наблюдения и разбора ошибок Merchant Center.
Перед сдачей проверим
- Контрольный товар создаётся или обновляется через ProductInput и появляется в обработанном Product с ожидаемыми атрибутами.
- Цена и остаток проходят выбранный маршрут, а запись сохраняет связь с account, dataSource, feed label и offerId.
- Замечание Merchant Center попадает в журнал рядом с конкретным товаром и понятным результатом обработки.
- Полная выбранная выгрузка завершается по расписанию, а повтор обновляет существующие товары без дублей.
Как это выглядит на практике
Товар из PIM обновляется через Merchant API и сохраняет историю
- 01
PIM передаёт SKU, offerId, язык, feed label, цену и остаток в загрузчик Merchant API.
- 02
Загрузчик выбирает закреплённый dataSource и отправляет ProductInput с устойчивым resource name.
- 03
После обработки Google интеграция читает Product, сохраняет статус и связывает замечание с полем PIM.
- 04
Следующий запуск обновляет ту же позицию, а журнал показывает account, источник и итог операции.
Что понадобится для работы
От вас
- Код интеграции Content API, перечень используемых методов, расписаний и примеры последних журналов загрузки.
- Доступ к Google Cloud project и Merchant Center с правами на основной аккаунт и выбранные подаккаунты.
- Список datafeed, dataSource, языков, feed label и контрольных SKU с ожидаемыми ценами и остатками.
- Схема CMS, PIM либо ERP и перечень отчётов или статусов, которые получает бизнес из Merchant Center.
Если у вас немного другая ситуация
Небольшие уточнения, которые помогают довести согласованный результат до рабочего состояния, уже учитываем в цене. Если по ходу работы появится отдельный крупный блок или понадобится платная лицензия, сначала обсудим варианты и стоимость. Расскажите о своей ситуации — подстроим план под неё.
- 3 000 ₽после подписания договора через Диадок
- 76 900 ₽после выполнения, демонстрации и приёмки результата
Предоплата входит в общую стоимость. Оставшуюся сумму оплачиваете после демонстрации и приёмки готовой работы.
Часто спрашивают
Об этой услуге
Когда Google отключил Content API for Shopping?
Google завершил доступ 18 августа 2026 года. После этой даты программный каталог переводится на Merchant API и его отдельные sub-API.
Требуется ли новая авторизация для Merchant API?
Требуется однократная developer registration, связывающая Google Cloud project с основным Merchant Center аккаунтом. OAuth 2.0 или сервисный аккаунт настраиваются по действующей архитектуре.
Чем ProductInput отличается от Product?
ProductInput хранит данные, отправленные конкретным источником продавца. Product показывает обработанный Google результат, объединённые данные, статус и замечания.
Почему важно сохранить offerId и dataSource?
Тот же offerId помогает сохранить историю товара, а правильный dataSource удерживает позицию в её источнике и под действующими правилами Merchant Center.
Что используется вместо productstatuses?
Статусы и проблемы товара входят в ресурс Product через productStatus. Интеграция читает их после обработки ProductInput и записывает рядом с внутренним SKU.
Как заменить custombatch для большого каталога?
Используем HTTP batching, асинхронные запросы либо клиентскую библиотеку с gRPC. Параллелизм ограничивается квотами, а результат сохраняется для каждого товара.
Можно сохранить существующие источники Content API?
Merchant API умеет работать с такими источниками через их resource names. Стратегию сохранения либо создания новых DataSource выбираем после проверки правил и структуры аккаунта.
Как принимается переход на Merchant API?
Проверяем создание, обновление, чтение статуса и удаление контрольного товара, затем прогоняем выбранный каталог, остатки и отчёт по рабочему расписанию.
Цена и изменения по ходу работы
Цена на странице окончательная?
Да. Перед началом мы сверяем исходные данные и фиксируем результат в договоре. Указанная на странице сумма покрывает согласованную работу целиком, даже если её техническая реализация потребует больше времени, чем ожидалось при оценке.
Что означает резерв незапланированных работ?
Это уже включённый в цену запас времени на небольшие связанные уточнения заказчика, которые появляются после старта: например, добавить поле, изменить формат уведомления или учесть ещё одно условие обработки.
Резерв рассчитывается по формуле: стоимость услуги × 30% ÷ 1 500 ₽. Для услуги за 30 000 ₽ это 6 часов. Эти часы относятся только к дополнительным, заранее незапланированным уточнениям. Они не являются сроком проекта и не ограничивают время на основную работу: согласованный результат мы выполняем полностью.
Можно уточнять детали уже во время работы?
Да. Небольшие связанные изменения обычно помещаются во включённый резерв и не требуют доплаты. Если новая идея заметно меняет результат или превращается в самостоятельную задачу, сначала обсудим подход и стоимость. Любое решение согласуем до выполнения.
Начало работы и оплата
Как оформляются договор и оплата?
Подписываем договор через Диадок. Предоплата составляет 3 000 ₽ и входит в общую стоимость услуги. Остаток оплачивается после демонстрации и приёмки готового результата.
Когда начинается срок выполнения?
Срок отсчитывается после согласования задачи, получения необходимых доступов и материалов, подписания договора и поступления предоплаты. Конкретную дату старта и плановый день готовности подтверждаем перед началом.
Как учитываются платные лицензии и внешние сервисы?
До старта проверяем, нужны ли тарифы, лицензии, сертификаты или дополнительные ресурсы внешних систем. Если они потребуются, заранее покажем варианты и стоимость. По возможности аккаунты и лицензии оформляются сразу на заказчика.
Проверка результата и гарантия
Как принимается готовая работа?
Вместе проверяем согласованные сценарии на контрольных данных или тестовой копии, а затем демонстрируем результат. Для интеграций сверяем передачу данных и обработку ошибок, для сайта — работу нужных страниц и действий пользователя, для отчёта — расчёты и обновление данных.
Какая гарантия действует после сдачи?
На выполненные изменения действует гарантия 3 месяца. Если в изменённой нами части обнаружится ошибка нашей реализации, проверим и исправим её без дополнительной оплаты. Переданные материалы, настройки и код остаются у заказчика.
Связанные шаги
- 01Товарный фид для маркетплейса или рекламной площадки
Подготовить товарные данные для площадки
- 02Переход Google Merchant Center с Content API на Merchant API
Перевести Merchant Center на актуальный API
- 03Мониторинг YML и XML-фидов, цен и остатков
Контролировать ошибки товарных фидов