Интеграция с маркетплейсами: остатки, цены и заказы без ручной работы в кабинетах

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

Схема хранения определяет, что вообще нужно интегрировать. Названия у площадок разные, смысл сводится к трём вариантам.

Главный операционный риск. Один физический склад продаёт в четыре канала — свой сайт и три площадки, — и каждый канал считает, что товар его.

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

Размер буфера — не константа. По быстрому товару его держат больше, потому что за интервал обновления успевают продать несколько единиц; по медленному он почти не нужен. Практичный способ — считать буфер от средних продаж за интервал обмена и пересматривать раз в сезон, а по последней единице просто закрывать продажу.

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

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

Цена на площадке — это не одно число. И набор полей у площадок разный, что регулярно ломает наивную выгрузку.

Тонкость, из которой растёт половина дефектов. Площадки в большинстве случаев не присылают событие о новом заказе — система сама периодически спрашивает: «что появилось».

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

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

Третий — срок. При работе со своего склада на сборку даётся ограниченное время, и опрос раз в час превращает нормальный процесс в просрочку. Частота опроса — не настройка удобства, а параметр, от которого зависят санкции.

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

Площадки ограничивают частоту вызовов, и при превышении метод отвечает кодом 429. Для интеграции это означает, что запросы нельзя отправлять по мере готовности.

Рабочая схема выглядит так. Все вызовы идут через ограничитель, который выдаёт разрешения по алгоритму вроде Token Bucket или Leaky Bucket. Параметры лимита площадка присылает в заголовках ответа и меняет их без предупреждения, поэтому ограничитель читает заголовки и подстраивается. Если у вас несколько процессов, квоту нужно делить между ними через общее хранилище, иначе каждый считает лимит своим.

Дальше — приоритеты. При нехватке квоты первыми должны проходить остатки и заказы, а обновление карточек может подождать. Без приоритезации выгрузка тысячи карточек съедает квоту, и в это время не обновляются остатки.

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

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

Выгрузка карточек тормозит проект по трём причинам.

• Характеристики зависят от категории. У обуви одни обязательные поля, у бытовой техники другие, и справочник значений у площадки свой. Ваш каталог обычно не содержит половины этих полей.
• Модерация асинхронная. Карточка уходит на площадку и возвращается с ошибкой через время. Значит нужна очередь, статусы и экран, где менеджер видит, что именно не приняли.
• Модификации. Размеры и цвета площадки моделируют по-разному, и сопоставление вариантов приходится делать отдельным механизмом.

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

Практичный порядок такой. Сначала запускаем обмен остатками и заказами по уже созданным карточкам, потому что это приносит деньги сразу. Автоматическую публикацию карточек добавляем вторым этапом.

Обратный поток меняет и остаток, и деньги, и его почти всегда проектируют последним.

Отмена до сборки. Заказ снимается, остаток возвращается в продажу. Просто, если система вовремя узнала об отмене.

Невыкуп. Покупатель не забрал заказ, товар едет обратно. На складе он появится через дни или недели, и до этого момента его нельзя ни продать, ни считать потерянным.

Возврат после выкупа. Товар возвращается в другом состоянии и иногда в другую точку. Часть возвратов уходит в уценку, и это отдельная позиция каталога.

Товар в пути обратно. Самое частое расхождение в учёте. Физически товара нет ни на складе, ни у покупателя, по документам он числится, и без отдельного статуса остаток по нему считается неверно.

Каждый из четырёх случаев обязан быть отдельным состоянием в системе. Схема «заказ отменён, всё вернули» работает до первого невыкупа.

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

На этом участке система делает четыре вещи.

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

Бухгалтерии от того же обмена нужно другое. Площадка выступает агентом, поэтому в учёт должны попасть и сумма продажи покупателю, и удержанное вознаграждение, и документы по нему. Если в учётную систему уезжает только чистая выплата, выручка занижается, а расходы просто исчезают.

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

С 1 октября 2026 года вступает в силу федеральный закон № 289-ФЗ о регулировании платформенной экономики. Он меняет отношения продавца и площадки, и часть требований прямо превращается в функции системы.

• Договор в электронной форме через платформу, с зафиксированными размером комиссии, порядком расчётов и сроками перечисления денег. Продавец сохраняет доступ к текущим и архивным версиям.
• Скидка за счёт продавца — только с его согласия, с уведомлением не менее чем за пять рабочих дней. Продавец вправе запретить скидки или установить минимальную цену, и отказ не может быть основанием для блокировки.
• Досудебный разбор ограничений. Жалобу рассматривают в срок до 15 дней, а при её обоснованности неправомерные ограничения снимают в течение 48 часов.
• Акты сверки по запросу в течение 7 дней, обновление финансовых расчётов ежемесячно.

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

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

Хвост семантики вокруг темы почти целиком про учётную систему: продавцы ищут интеграцию площадок с типовыми конфигурациями. Вопрос при этом не в том, куда подключаться, а в том, где держать логику синхронизации.

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

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

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

Объём работ задают три параметра. Число площадок, число схем работы и наличие сверки выплат. Одна площадка по FBO — это несколько недель, четыре площадки в двух схемах со сверкой — совсем другой проект.

По нашим работам: отдельная интеграция с площадкой, службой доставки или учётной системой — от 150 тыс. до 1,5 млн ₽ за одну, свой канал продаж с витриной — от 1,5 млн ₽, заказная система обмена под процесс — от 1,7 млн ₽, аудит существующего обмена — от 200 до 600 тыс. ₽. Точную цифру считаем по составу площадок и схем: оценка проекта бесплатная.

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

Остаток отдают целиком. Буфера нет, реакция медленная, товар продан дважды. Отмены растут, рейтинг падает, площадка снижает видимость.

Обмен ставят на общее расписание. Раз в час для всего сразу. Остатки устаревают, заказы приезжают с опозданием, а карточки при этом обновлять было незачем.

Лимиты не считают. Первая массовая выгрузка ловит код 429, площадка притормаживает интеграцию, продажи стоят.

Минимальную цену не заводят. Товар уходит в акцию площадки и продаётся ниже себестоимости, а узнают об этом из отчёта о реализации.

Сверку выплат откладывают. Полгода компания видит выручку и не видит маржу по товару. Разобрать накопившиеся расхождения к этому моменту уже нереально.

Первое — выписать матрицу «площадка × схема работы». Обычно оказывается, что схем больше, чем думали, и часть товаров живёт сразу в двух. Эта матрица определяет объём проекта точнее любого описания задачи.

Второе — измерить ручную работу. Сколько человеко-часов в неделю уходит на правку остатков и цен в кабинетах, сколько заказов переносится руками, сколько отмен случилось за месяц по причине «нет товара». Три числа сразу показывают, что чинить первым.

Третье — решить вопрос про источник истины. Какая система знает правильный остаток и правильную цену. Пока на этот вопрос нет однозначного ответа, любая интеграция будет разъезжаться.