Интеграция маркетплейсов: Ozon, WB, FlowWow

Продавец работает на трёх маркетплейсах. На каждом — свой личный кабинет, свои остатки, свои заказы. Менеджер переключается между тремя вкладками, вручную переносит данные в МойСклад, сверяет остатки в таблице. Один маркетплейс обновил API — скрипт сломался, остатки не обновились, пошли отмены.

Это типичная ситуация для бизнеса, который вырос с одной площадки до нескольких. И каждый новый канал продаж кратно увеличивает объём ручной работы — если каналы между собой не связаны.

В этой статье разберём, как устроена интеграция маркетплейсов с учётными системами: какие задачи она решает, как выглядит архитектура и с какими ограничениями придётся считаться. Без теории — на примерах реальных проектов с Ozon, Wildberries, FlowWow и СберМаркет.

Что значит «интеграция маркетплейса»

Интеграция — это не выгрузка CSV и не ручной импорт. Это двусторонний автоматический обмен данными между маркетплейсом и вашей учётной системой: МойСклад, Google Таблицы, CRM или любой другой инструмент, в котором ведётся учёт.

Что это означает на практике:

Заказ приходит на маркетплейсе — и автоматически создаётся в складской системе, готовый к сборке.
Остатки обновляются в одном месте — и все маркетплейсы видят актуальное количество.
Цены меняются в таблице — и через минуты обновляются на всех площадках.
Статусы синхронизируются: собрали заказ в МойСклад — маркетплейс узнал.

Ключевое отличие от «скрипта, который раз в час дёргает API»: настоящая интеграция обрабатывает ошибки, не теряет данные при сбоях и работает без участия человека. Про разницу между скриптом на cron и интеграцией мы подробно писали в статье об архитектуре.

Четыре задачи, которые решает интеграция

1. Синхронизация остатков

Главная боль мультиканальных продавцов — overselling. Товар продали через один канал, а на другом остатки не обновились. Результат: принятый заказ на товар, которого нет, отмена, штраф от площадки, негативный отзыв.

Решение — единый источник правды по остаткам. Это может быть МойСклад, Google Таблица или собственная база. Любое изменение — приёмка, продажа, списание — автоматически обновляет остатки на всех площадках.

Как это работает у наших клиентов:

На Ozon остатки обновляются через Seller API. Мы загружаем данные из таблицы и обновляем по расписанию или вручную.
На Wildberries схема зависит от модели: при FBO остатки ведёт сам маркетплейс, при FBS — продавец. Мы автоматизировали оба варианта.
На FlowWow остатки проверяются перед принятием каждого заказа — если товара нет в МойСклад, заказ мгновенно отклоняется.

2. Обработка заказов

Вторая по частоте задача — убрать ручной перенос заказов из кабинета маркетплейса в учётную систему.

В проекте FlowWow + МойСклад мы убрали полностью: заказ приходит на маркетплейс — через 30 секунд он уже в МойСклад, готовый к сборке. В пиковый день (8 марта) система обработала 330 заказов без единого ручного действия. Без интеграции это было бы 16–28 часов ручной работы.

В проекте LasFlore + СберМаркет задача была сложнее: у маркетплейса вообще не было личного кабинета для продавцов. Единственный способ работать — через API. Мы встроили заказы из СберМаркета в ту же Google Таблицу, где менеджеры обрабатывали заказы с других площадок. Команда даже не заметила, что появился новый канал продаж.

3. Управление ценами

На конкурентных рынках цены меняются каждый день. Промоакции, ответ конкурентам, сезонные корректировки, изменение себестоимости — всё это требует оперативных обновлений.

В кейсе с Ozon продавец управляет ценами на 4 000 SKU из Google Таблицы. Менеджер проставляет новые цены, нажимает кнопку — и изменения уходят через API. Время обновления сократилось с 3 часов до 5 минут. За полгода — ноль ценовых ошибок вместо трёх инцидентов с суммарными потерями 50 000+ рублей за квартал.

Дополнительно работает валидация: скрипт не отправит цену ниже минимальной маржи. И планировщик: промоцены выставляются и снимаются автоматически по расписанию.

4. Каталог и контент

Менее очевидная, но важная задача — синхронизация каталога. Когда вы продаёте на нескольких площадках, карточки товаров приходится вести в каждом кабинете отдельно. Добавили новый товар — нужно создать карточку на каждом маркетплейсе.

В проекте LasFlore каталог выгружается на СберМаркет автоматически каждые 3 часа: категории, товары, изображения, цены. Добавили букет на сайт — он появляется на маркетплейсе при следующей синхронизации.

Как это устроено технически

Каждую интеграцию мы строим как конвейер из трёх слоёв: получение данных, обработка, доставка в целевую систему. Между слоями — очередь задач, которая гарантирует, что данные не потеряются даже при сбоях.

Ключевые принципы:

Очередь задач. Каждая операция (заказ, обновление цены, синхронизация остатков) — отдельная задача в очереди. Если API маркетплейса временно недоступен, задача не теряется — она ждёт и повторяется.
Retry с backoff. Временные ошибки (429, 500, таймауты) обрабатываются автоматически с нарастающей паузой между попытками.
Идемпотентность. Повторная обработка одного и того же заказа не создаёт дубликаты.
Мониторинг. Если что-то пошло не так — Telegram-уведомление. Проблема решается до того, как заказы начинают копиться.

Подробнее об архитектуре, стеке и подходе — в отдельной статье.

Кейсы из нашей практики

FlowWow + МойСклад

Флористический магазин, заказы с Flowwow переносились в МойСклад вручную. В пиковый день — 330 заказов, 16–28 часов ручной работы.

Построили сервис на Node.js + BullMQ: проверка новых заказов каждые 30 секунд, автоматическое принятие/отклонение, создание заказа в МойСклад. Менеджер открывает МойСклад и видит готовые заказы.

Результат: 0 минут ручной работы в пиковый день, ответ на заказ за 30 секунд вместо 3–5 минут. Полный кейс →

LasFlore + СберМаркет

Цветочный магазин подключил новый канал продаж — СберМаркет. Проблема: у маркетплейса не было личного кабинета для продавцов. Работать можно только через API.

Встроили заказы из СберМаркета в ту же Google Таблицу, где менеджеры работали с другими каналами. Цены синхронизируются каждые 10 минут, каталог — каждые 3 часа.

Результат: новый канал продаж — 0 минут на обучение команды. За 21 месяц — 51 доработка (интеграция — это процесс, не «сделали и забыли»). Полный кейс →

Ozon: цены на 4 000 SKU

Продавец бытовой химии на Ozon. 4 000 товаров, ежедневные изменения цен, участие в промоакциях.

Центр управления ценами в Google Таблице: дашборд по всем SKU, валидация по марже, планировщик промоцен.

Результат: обновление с 3 часов до 5 минут, 0 ценовых ошибок за 6 месяцев, экономия 200 000+ руб./год. Полный кейс →

Wildberries: остатки и заказы

Синхронизация остатков и загрузка заказов через Wildberries API в Google Таблицу. Поддержка FBO и FBS схем.

Подробнее →

Особенности каждого маркетплейса

Маркетплейсы — не одинаковые. У каждого свой API, свои ограничения, свои подводные камни.

Параметр	Ozon	Wildberries	FlowWow	СберМаркет
Получение заказов	API polling	API polling	API polling	Webhook
Обновление остатков	REST API	REST API	Нет (проверка при заказе)	REST API
Обновление цен	REST API (пакеты по 100)	REST API	Нет	REST API
Rate limits	60 req/min (цены)	300 req/min	Не документировано	По договорённости
Личный кабинет	Полноценный	Полноценный	Полноценный	Не было на момент интеграции
Документация API	Хорошая, часто обновляется	Средняя	Минимальная	Внутренняя

Главный вывод: нельзя написать один универсальный коннектор для всех маркетплейсов. Каждая интеграция — отдельный адаптер с учётом специфики API.

Что нужно для старта

Чтобы подключить маркетплейс к учётной системе, нужны три вещи:

Доступ к API маркетплейса. На Ozon и Wildberries — ключи из личного кабинета. На некоторых площадках — договор на подключение.
Центральная система учёта. МойСклад, Google Таблица, 1С, собственная база — то место, где ведутся остатки, заказы и цены. Если такого места нет — интеграцию ставить некуда.
Понимание, какие процессы автоматизировать первыми. Необязательно делать всё сразу. Обычно начинают с остатков (чтобы не было overselling) или заказов (чтобы убрать ручной перенос).

Не уверены, с чего начать? Пройдите квиз за 2 минуты — покажем, какие процессы стоит автоматизировать в первую очередь.

Типичные сроки и стоимость

Здесь важно быть честными: «интеграция маркетплейса» — это не фиксированный продукт с ценником. Стоимость зависит от количества маркетплейсов, сложности бизнес-логики и целевой системы.

Ориентиры из наших проектов:

Задача	Сроки	Стоимость	Типичная окупаемость
Остатки + заказы, один маркетплейс	2–4 недели	от 80 000 ₽	2–3 месяца
Полная интеграция (остатки, заказы, цены), МойСклад	4–6 недель	от 120 000 ₽	2–4 месяца
Мультиканальная интеграция (2–3 маркетплейса)	6–10 недель	от 200 000 ₽	3–6 месяцев

Поддержка — отдельная статья. Маркетплейсы обновляют API, бизнес меняет требования, в бою находятся баги. В проекте LasFlore за 21 месяц мы сделали 51 доработку. Интеграция с внешним API — это процесс, а не разовая задача.

Ограничения

Было бы нечестно не рассказать о том, с чем придётся считаться.

Rate limits. Каждый маркетплейс ограничивает количество запросов к API. На Ozon — 60 в минуту для ценовых эндпоинтов. На Wildberries — 300 в минуту. Если интегрируете несколько процессов (остатки + заказы + цены), лимиты делятся между ними.

API меняется. Ozon обновляет API регулярно — за полгода мы дважды адаптировали скрипты. Wildberries может поменять авторизацию. На поддержку закладывается 2–3 часа в месяц на маркетплейс.

Каждый маркетплейс — отдельная разработка. Нет универсального коннектора. FlowWow работает не так, как Ozon, а СберМаркет — не так, как FlowWow. Добавление нового маркетплейса — это новый адаптер, новое тестирование, новые edge cases.

Google Таблицы — не база данных. Для 4 000 строк таблица справляется. При 10 000+ начинаются тормоза. Для крупных продавцов может потребоваться миграция на PostgreSQL или BigQuery.

Интеграция не исправит хаос в данных. Если в учётной системе неправильные остатки — они будут неправильными и на маркетплейсах. Автоматизация ускоряет процессы, но не заменяет порядок в данных.