Карантин весны 2020-го перегнал офлайн-продажи в онлайн, и маркетплейсы стали основным каналом для тысяч поставщиков. Ozon, Wildberries, Беру, AliExpress Russia – у каждого свой кабинет, свой формат прайса, свои правила отгрузки. Пока товаров сотня, менеджер обновляет остатки руками в Excel. На тысячах SKU и нескольких площадках ручной труд ломается: цены расходятся, заказы теряются, склад уходит в минус. Решение одно – связать учётную систему с площадками через API и убрать человека из рутины.

Что именно синхронизировать

Интеграция разбивается на четыре потока, и каждый живёт по своему расписанию.

Каталог и цены. Карточки заводятся редко, цены меняются часто. Выгружайте номенклатуру пакетами, а изменение цен шлите отдельным быстрым потоком. У Wildberries и Ozon приём прайса асинхронный: вы отправляете задание и получаете идентификатор, статус опрашиваете позже. Считать загрузку успешной по факту ответа 200 – ошибка, проверяйте результат обработки.

Остатки. Самый чувствительный поток. Один склад на несколько площадок – это гонка за последней единицей товара. Держите остатки в своей системе как единый источник правды и раздавайте их площадкам с резервом под уже принятые, но ещё не отгруженные заказы. Частота обновления – минуты, не часы.

Заказы. Забирайте новые заказы по расписанию или вебхуком, сразу резервируйте товар и отдавайте статусы обратно: собран, передан в доставку, отменён. Идемпотентность обязательна – один и тот же заказ площадка может прислать дважды.

Логистика. Для модели FBS (продавец хранит и отгружает сам) добавляются ярлыки, маркировка коробов, расписание отгрузок на склад площадки. Печать стикеров и формирование поставки – тоже через API.

Как не сломаться об ограничения API

API маркетплейсов капризны: лимиты запросов, плавающие тайм-ауты, плановые работы по ночам, разные версии у разных площадок. Стройте интеграцию как набор очередей с повторами, а не как синхронные вызовы из учётной системы напрямую.

Базовые правила, которые экономят недели отладки:

  • Очередь на каждый поток с ограничением скорости под лимит конкретной площадки.
  • Экспоненциальные повторы при 429 и 5xx, dead-letter для застрявших задач.
  • Журнал каждого вызова с запросом, ответом и временем – без него разбор расхождений превращается в гадание.
  • Сверка раз в сутки: что в нашей системе против того, что в кабинете площадки.

Архитектурные принципы для такой нагрузки мы разбирали в статье про устройство e-commerce под маркетплейсы, а подход к пиковым нагрузкам – в материале о масштабировании под нагрузкой.

Где это живёт

Коннекторы к площадкам – это сервисы, которые работают непрерывно и переживают рост числа SKU и заказов. Мы выносим их в отдельные контейнеры и катим в Kubernetes: каждый коннектор масштабируется независимо, падение одной площадки не роняет остальные. Для госсектора и крупного ритейла добавляем разграничение доступа, аудит операций и хранение журналов в контуре заказчика.

Вывод

Интеграция с маркетплейсами – не разовый импорт прайса, а постоянный двусторонний обмен с защитой от сбоев на стороне площадок. Правильно собранный слой синхронизации убирает ручной труд, держит остатки честными и масштабируется на новые площадки без переписывания. Связать учётную систему с маркетплейсами и довести обмен до промышленной надёжности – это и есть интеграция учётной системы с внешними площадками через API.