Разбираем архитектуру синхронизации каталога, остатков и заказов между 1С-Битрикс и маркетплейсами через Seller API: какие расхождения возникают на практике и как их избежать.
Когда интернет-магазин на 1С-Битрикс выходит на маркетплейсы — Ozon, Wildberries, Яндекс.Маркет — возникает задача, которая на первый взгляд кажется простой: выгрузить те же товары туда же, куда уже продаётся на сайте. На практике это одна из самых требовательных к архитектуре интеграций, потому что данные должны синхронизироваться в обе стороны, в реальном времени, и цена ошибки — не сломанная страница, а реальный проданный товар, которого физически нет на складе.
Что решает Seller API и почему это не просто выгрузка каталога
Seller API в экосистеме Битрикса — это набор методов, через которые каталог, остатки и заказы синхронизируются между магазином на платформе и внешними торговыми площадками. В отличие от разовой выгрузки товарного фида, это двусторонний поток: магазин отправляет на маркетплейс актуальные цены и остатки, а обратно получает новые заказы, которые нужно обработать так же, как заказы с собственного сайта — списать товар со склада, передать в 1С, отразить в CRM.
Главная архитектурная сложность в том, что у каждого маркетплейса — своя модель данных, свои требования к категоризации товаров, свой формат характеристик и свои правила расчёта комиссии. Простого «одинакового API для всех площадок» не существует: интеграция фактически представляет собой набор адаптеров, каждый из которых переводит внутреннюю модель каталога Битрикса в формат конкретной площадки.
Синхронизация остатков — самое узкое место
Основная проблема, с которой сталкиваются продавцы на нескольких площадках одновременно, — овербукинг (oversell): товар продан на маркетплейсе, но остаток на сайте и в 1С ещё не успел обновиться, и тот же товар продаётся повторно на другом канале. Классическая периодическая синхронизация «раз в час» здесь недостаточна для товаров с высокой оборачиваемостью — расхождение в остатках накапливается быстрее, чем система успевает его исправить.
Правильная архитектура строится на событийной модели: при подтверждении заказа на любом канале (сайт, маркетплейс, оффлайн через 1С) немедленно отправляется событие уменьшения остатка на все остальные каналы, а не ожидается очередной цикл синхронизации по расписанию. Похожие принципы синхронизации остатков и заказов между сайтом и учётной системой мы разбирали в статье «Настройка и интеграция 1С с сайтом: как связать каталог, заказы и остатки» — при подключении маркетплейсов эта же логика должна распространяться ещё на один или несколько внешних каналов, а не только на связку «сайт — 1С».
- событийное уменьшение остатка сразу при подтверждении заказа на любом канале продаж;
- резервирование товара на время оформления заказа, чтобы избежать гонки между одновременными покупками на разных площадках;
- отдельный буфер (страховой остаток), который не выгружается на маркетплейсы, если расхождения по факту всё же случаются;
- алерты при обнаружении отрицательного остатка — сигнал, что синхронизация где-то дала сбой.
Обработка заказов и статусов между системами
Вторая по сложности задача — сопоставление статусов заказа. У каждого маркетплейса своя воронка статусов (принят, собран, передан в доставку, доставлен, возврат), и эти статусы нужно смаппить на внутреннюю логику заказов в Битриксе, а зачастую и дальше — в 1С для бухгалтерского учёта. Прямое однозначное соответствие статусов редко существует: например, «возврат» на одной площадке может означать частичный возврат товара, а не отмену всего заказа, и обработка этого случая должна учитывать частичность.
Мы разбирали похожую задачу получения и обработки товарных позиций заказа через API Битрикса в статье «Получение товаров заказа 1С-Битрикс API» — при интеграции с маркетплейсами эта логика усложняется тем, что источник заказа внешний, и нужно предусмотреть идемпотентную обработку: маркетплейс может повторно отправить уведомление о заказе при сбое соединения, и система не должна создать по нему задвоенный заказ в CRM.
Как мы проектируем интеграции с маркетплейсами
В Codeking при подключении маркетплейсов мы начинаем с построения единой модели остатков — центрального источника истины, к которому обращаются все каналы продаж, вместо того чтобы синхронизировать остатки напрямую между каждой парой систем. Это упрощает добавление новой площадки в будущем: не нужно писать интеграцию «маркетплейс — сайт» и «маркетплейс — 1С» отдельно, достаточно подключить новый канал к единому центру остатков.
Для заказов мы проектируем единый внутренний формат, к которому приводятся заказы со всех каналов ещё на входе — это позволяет менеджерам и системе учёта работать с заказами одинаково, независимо от того, пришёл он с сайта, из маркетплейса или был создан вручную. Такой подход снижает количество мест, где может возникнуть рассинхронизация, и делает добавление новых каналов продаж предсказуемой задачей, а не отдельным проектом каждый раз.