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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В проекте Flowwow + МойСклад мы убрали полностью (что входит в такое подключение и сколько стоит — на странице интеграции Flowwow): заказ приходит на маркетплейс — через 30 секунд он уже в МойСклад, готовый к сборке. В праздники магазин принимает до 400 заказов с площадки в день; раньше под это нанимали двух дополнительных человек.

В проекте 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	Webhook + polling	Webhook
Обновление остатков	REST API	REST API	REST API	REST API
Обновление цен	REST API (пакеты по 100)	REST API	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.

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