Интеграция с Яндекс Маркетом по API помогает поддерживать ассортимент и обрабатывать продажи из внутренней системы компании. До разработки определяем модель работы — FBS, DBS или FBY — и границы кабинета, магазинов и складов. Возможности конкретной операции проверяем в актуальном API: единый кабинет не означает одинаковый маршрут исполнения для всех моделей.
Каталог, предложения и магазины
Сопоставляем SKU продавца с внутренними товарами, вариантами и действующими предложениями Маркета. Разделяем данные бизнеса и конкретного магазина там, где это предусмотрено API. При нескольких витринах не считаем одинаковый номер товара достаточным ключом без контекста кабинета.
Проверяем обязательные параметры категории, штрихкоды и изображения. Результат загрузки сохраняем по позициям: продавец должен понимать, что отклонено и какое поле исправить. Изменение описания и управление доступностью к продаже могут требовать разных операций.
Обновление цены и наличия
Определяем, какая система рассчитывает цену, как учитывает округление и что происходит с акционными условиями. Для остатка используем свободное для продажи количество, а не весь физический запас. При общем складе учитываем продажи собственного сайта и других каналов.
Передача остатка в интеграции с Яндекс Маркетом включает соответствие SKU и склада, а для применимого метода — актуальность значения по времени. Правила групп складов проверяем отдельно. Старое сообщение не должно возвращать на витрину уже проданный товар; нулевой остаток проходит обязательный контрольный сценарий.
Остатки между сайтом и площадками
При общем складе продажи Маркета должны учитываться вместе с заказами собственного магазина и других площадок. Этот общий контур раскрыт отдельно.
Обмен магазина с маркетплейсамиЗаказы FBS и DBS
Для FBS рассматриваем получение заказа, сборку и доступные действия отгрузки. При DBS отдельно согласуем собственную доставку и статусы её выполнения. Правила отмены, изменения и подтверждения зависят от модели. Во внутренней системе сохраняем состав, идентификатор заказа и источник каждого состояния.
Событийные уведомления используем там, где они доступны, а контрольную сверку — для восстановления пропусков. Полученное уведомление не даёт права выполнять любое действие: перед изменением проверяем текущее состояние заказа и допустимый переход. Неверную последовательность событий разбираем по журналу.
Данные FBY, возвраты и отчёты
Если товар хранится у Маркета, определяем нужные сведения о наличии, продажах и поставках по доступным интерфейсам. Не создаём внутреннее задание сборки продавцу только потому, что оно требуется в сценарии FBS. Физическое движение и его отражение в учёте описываем отдельно.
Для невыкупов и возвратов сохраняем связь с исходным заказом и этапами фактического получения товара. Финансовые данные сверяем с принятыми правилами учёта услуг, удержаний и корректировок. Сумма заказов за день не подменяет отчёт о выплате продавцу.
Как запускаем обмен
Выдаём отдельный API-Key с необходимыми доступами, фиксируем методы и источники данных. Для больших каталогов предусматриваем пакетную обработку, пагинацию и журнал частичных отказов. Лимиты и признаки устаревших методов проверяем по документации перед запуском.
Приёмка включает товар с ошибкой, смену цены, исчерпание остатка, новый и отменённый заказ, повтор уведомления и восстановление после остановки. Заказчик получает работающий обмен, таблицу соответствий и порядок контроля. Для оценки нужны модель продаж, магазины, склады и описание внутренней системы.
Вопросы перед началом работ
Одна интеграция подойдёт для всех моделей Маркета?
Общий транспорт и каталог можно использовать совместно, но исполнение заказов и доступные действия зависят от FBS, DBS или FBY. Состав сценариев фиксируем отдельно и проверяем по текущему API.
Можно оставить загрузку части данных файлами?
Да, если чётко разделить ответственность. Например, один источник обновляет контент, другой — остаток. Два маршрута не должны одновременно переписывать одно поле без правил приоритета.
Как быстро обновляется остаток?
Срок зависит от источника, расписания, очереди и обработки на стороне площадки. Обсуждаем требуемую актуальность, затем проверяем задержку на вашем сценарии. Само наличие API не означает мгновенную синхронизацию.
Можно подключить несколько магазинов одного бизнеса?
Да, с отдельными соответствиями магазинов, складов и объектов. Общие данные каталога не отменяют раздельного контроля заказов и доступов.
Что происходит при повторном уведомлении?
Событие сверяется с уже обработанным заказом и текущим состоянием. Повтор доставки не создаёт новый внутренний заказ. Для пропущенных уведомлений предусматриваем согласованную сверку.