Маркетплейс отдаёт по API пять групп данных, и задержка у них различается на пять порядков: новый заказ виден через минуты, подтверждение принятого остатка — через десятки минут, отчёт о реализации приходит после закрытия периода, а удержания и компенсации доезжают в течение полутора месяцев и переписывают уже закрытые дни. Проектировать обмен «в реальном времени» под такой набор нельзя. Проектировать надо под очередь, задержку и последующую сверку.
Это главное, что стоит понять до выбора подрядчика или сервиса. Фраза «подключим маркетплейс за неделю» обычно означает подключение первого контура — заказов. Он действительно делается быстро. Остальные четыре контура и весь узел сверки денег живут по другим правилам, и именно на них проект растягивается с недели до полутора-двух месяцев.
Ниже — свойства этих API как инженерного объекта: что и когда появляется, почему отправка не равна приёму, как устроены лимиты и повторы, откуда берётся расхождение между кабинетом и учётной системой и по каким трём критериям выбирают между готовым сервисом связи и собственным слоем обмена. Организация самой торговли на площадках — схемы работы, распределение остатка, карточки — разобрана отдельно в материале про интеграцию магазина с площадками; здесь мы смотрим на трубу, а не на товар в ней.
Пять групп данных и задержка каждой
Разные группы данных живут по разным законам, и смешивать их в одном задании обмена — самая частая архитектурная ошибка. Конкретные величины у площадок различаются и меняются несколько раз в год, поэтому в таблице ниже указаны порядки, а не гарантии: точные значения берутся из документации на день работ.
| Группа данных | Направление | Типичная задержка | Чего с ней делать нельзя |
|---|---|---|---|
| Заказы и сборочные задания | С площадки в учёт | Минуты с момента оформления | Считать выручкой: заказ отменяется покупателем в любой момент до отгрузки |
| Статусы отправлений | В обе стороны | От минут до нескольких часов | Строить на них мгновенные уведомления клиенту без запаса по времени |
| Остатки | Из учёта на площадку | От минут до получаса до появления на витрине | Считать выгруженное количество тем, что видит покупатель прямо сейчас |
| Цены и карточки | Из учёта на площадку | Часы, у карточек — до нескольких суток из-за модерации | Планировать акцию впритык: цена может не успеть примениться к началу |
| Отчёты о реализации, удержания, компенсации | С площадки в учёт | От нескольких дней до 45 суток, правки задним числом | Закрывать месяц по данным кабинета на первое число: половина строк ещё не пришла |
Из таблицы следует практическое правило расписания. Остатки обновляются часто и только по изменившимся позициям, цены — реже и пакетом, карточки — отдельным медленным контуром, который вообще не обязан укладываться в сутки, заказы — по расписанию или по уведомлению площадки, а финансовые отчёты — раз в период с обязательным перезабором прошлых дат. Пять контуров с пятью расписаниями, а не одна кнопка «синхронизировать».
Горизонтальная логарифмическая шкала времени от «минуты» до «45 суток». На ней пять отметок с подписями: «Заказы и сборочные задания — минуты», «Статусы отправлений — минуты и часы», «Остатки — до получаса», «Цены и карточки — часы, карточки до нескольких суток», «Отчёты, удержания, компенсации — от дней до 45 суток». У последней отметки стрелка назад с подписью «правки задним числом». Чертёжный стиль, подписи по-русски.
Асинхронность: «отправлено» не значит «принято»
Почти всё, что вы отправляете на площадку, обрабатывается не в момент запроса. Вы передаёте пакет, получаете в ответ идентификатор задачи и дальше обязаны сами спросить, чем она закончилась. Между этими двумя событиями проходит от секунд до часов, и в этом промежутке пакет может быть принят целиком, принят частично или отклонён по позициям, которых нет в каталоге площадки.
Операция, у которой ответ на запрос содержит не результат, а номер задания. Результат забирается отдельным запросом позже. Практическое следствие: в журнале обмена должно быть два события на одну операцию — «отправлено» и «подтверждено площадкой», и считать по второму. Если система пишет только первое, вы видите зелёные галочки, а витрина показывает вчерашние данные.
- 1Шаг 1. Отбор изменившегося
Из учёта берутся только те позиции, у которых изменился остаток или цена с прошлого прогона. В каталоге на 1 200 позиций за 15 минут меняется 30–60 строк — остальные 1 140 гнать бессмысленно, они съедают лимит, который понадобится в час пик.
- 2Шаг 2. Отправка пакетом и получение номера задания
Позиции уходят одним пакетом, в ответ приходит идентификатор. Этот идентификатор пишется в журнал вместе со списком позиций пакета — без него потом невозможно понять, какие именно строки не доехали.
- 3Шаг 3. Опрос результата с паузой
Статус задания запрашивается не сразу и не в цикле: первая проверка через 30–60 секунд, дальше с нарастающим интервалом. Опрос без паузы — это трата того же лимита, из-за которой следующий пакет уже не пройдёт.
- 4Шаг 4. Разбор частичного результата
Площадка обычно отвечает построчно: столько-то принято, столько-то отклонено с кодом причины. Отклонённые строки не теряются, а попадают в очередь на повтор или в список для человека, если причина не устраняется автоматически.
- 5Шаг 5. Отметка в учёте
Позиция помечается как подтверждённая площадкой с датой и временем. Именно эта отметка, а не факт отправки, служит основанием считать, что витрина показывает актуальное число.
Самый опасный режим обмена — тот, где журнал считает сессии, а не строки. Пакет ушёл, ошибок нет, счётчик успешных обменов растёт, а фактически площадка приняла десятую часть позиций и остальное отклонила по кодам, которые никто не читает. Обнаруживается это обычно через отмены заказов и претензии покупателей, то есть через две-три недели и через рейтинг.
Лимиты, очередь и повторы
У каждого метода есть ограничение на число запросов в единицу времени и на размер пакета. Превышение наказывается не понятной ошибкой, а деградацией: часть запросов отклоняется, часть уходит в отложенную обработку. Дальше начинается контринтуитивная часть — попытка «пробить» ограничение частыми повторами продлевает паузу, потому что каждый отклонённый запрос всё равно засчитывается площадкой.
- 1Нарастающая пауза. Получили отказ по лимиту — следующая попытка не через секунду, а через удвоенный интервал: 5, 10, 20, 40 секунд и так далее до разумного потолка. Это единственная реакция, которая сокращает время до успешного ответа, а не увеличивает его.
- 2Одна очередь на площадку, а не на задание. Все контуры одного кабинета делят общий бюджет запросов. Если переоценка каталога и обновление остатков ходят двумя независимыми потоками без общей очереди, они гарантированно съедят лимит друг друга в самый неподходящий момент.
- 3Приоритеты внутри очереди. Остатки по ходовым позициям и приём новых заказов важнее выгрузки карточек. При исчерпании лимита откладывается медленный контур, а не критичный.
- 4Идемпотентность операций. У каждой отправки — свой ключ. Повтор с тем же ключом не создаёт вторую отгрузку и не пробивает остаток дважды. Без этого любая сетевая ошибка превращается в дубль, а дубли в отгрузках разбираются уже руками.
- 5Журнал операций с телом запроса и ответа. Хранить 30–90 дней. Это единственный способ доказать площадке или себе, что именно было отправлено в конкретную минуту, — и единственный способ починить расхождение, не гадая.
Схема из семи блоков со стрелками. Слева «Учёт: изменившиеся позиции» → «Пакет 100–1000 строк» → «Отправка, получен номер задания» → «Опрос результата: 30 с, 60 с, 120 с» → развилка на два блока: «Принято — отметка в учёте» и «Отклонено по лимиту — возврат в очередь с удвоенной паузой». Отдельной дорожкой снизу проходит «Журнал операций: запрос, ответ, ключ идемпотентности». Сбоку блок приоритетов: «остатки и заказы выше, карточки ниже». Чертёжная манера, подписи по-русски.
Почему кабинет и учёт показывают разные деньги
Это вопрос, который рано или поздно задаёт каждый владелец, и почти всегда ответ на него звучит как «интеграция сломалась». Обычно она не сломалась. Расхождение возникает из-за того, что кабинет площадки и учётная система фиксируют разные события в разные даты, и часть событий приходит задним числом.
Возьмём модельного продавца: 1 200 позиций в каталоге, три площадки, 90 заказов в сутки — 2 700 заказов в месяц при среднем чеке 2 400 ₽. Кабинеты по итогам месяца показывают 6 480 000 ₽ оформленных заказов. В учёте после закрытия периода стоит 6 122 000 ₽. Разница — 358 000 ₽, и она раскладывается на три понятные части.
Три вывода из этой арифметики. Первый: сверять кабинет и учёт по одной дате бессмысленно, сверка идёт по документу-основанию — отчёту о реализации, а не по дате заказа. Второй: закрывать месяц первого числа нельзя, потому что удержания и компенсации приходят до 45 суток; практический ориентир — предварительное закрытие на пятый рабочий день и окончательное после получения всех отчётов периода. Третий: расхождение нужно не устранять, а объяснять — у бухгалтерии должен быть регламент, который раскладывает разницу на составляющие. Механику такой сверки мы разбирали в решении по автоматической сверке документов.
В отчёте о реализации помимо базовой комиссии встречаются логистика, обратная логистика по возвратам, хранение, эквайринг, участие в акциях, штрафы за нарушение сроков и компенсации в вашу пользу. Пока эти строки не разложены по видам в учёте, себестоимость канала считается на глаз, и решение «какая площадка выгоднее» принимается по выручке — то есть по показателю, который к прибыли отношения не имеет.
Слой обмена, который переживает изменения API
Площадки меняют методы, состав полей и правила несколько раз в год. Обмен, в котором логика бизнеса написана прямо в обработчике конкретной площадки, переписывается при каждом таком изменении целиком. Обмен со своим промежуточным слоем меняется в одном адаптере. Разница в стоимости сопровождения — примерно двукратная, и она проявляется не в первый год, а во второй.
- Свой внутренний формат заказа, остатка и позиции. Адаптер площадки приводит её ответ к вашему формату на входе, вся остальная логика про конкретный маркетплейс ничего не знает.
- Справочник соответствий. Своя номенклатура — идентификатор площадки — штрихкод, в одной таблице с историей изменений. Без него после смены артикулов у поставщика обмен начинает жить своей жизнью, а виноватым выглядит подрядчик.
- Журнал операций с ключом идемпотентности. Каждая отправка и каждый приём — строка с телом запроса, ответом и результатом. Это же основа для повторов и для разбора спорных ситуаций.
- Очередь с приоритетами и нарастающей паузой — общая на кабинет, а не на задание. Она же переживает ночной сбой связи без потери данных.
- Экран расхождений для человека. Всё, что не разобралось автоматически: непринятые строки, заказы без сопоставленной номенклатуры, отчёты с необъяснённой разницей. Пять минут в день на этот экран дешевле, чем восстановление данных за квартал.
- Отдельный тестовый контур. Изменения обмена проверяются не на боевом кабинете: ошибка в выгрузке цен на живом каталоге стоит дороже, чем два дня работы на подготовку теста.
Карта связей в три колонки. Слева узел «Учётная система: 1С УТ, 1С УНФ или МойСклад». В центре широкий блок «Слой обмена» с четырьмя вложенными подписями: «внутренний формат», «справочник соответствий», «очередь с приоритетами», «журнал операций». Справа три одинаковых маленьких блока «адаптер площадки», каждый ведёт к своему узлу-площадке. Снизу отдельный узел «Экран расхождений — 5 минут в день» со стрелкой от слоя обмена. Подписи на стрелках: «заказы», «остатки», «отчёты о реализации». Чертёжная манера, надписи по-русски.
Что должно быть в учёте, чтобы площадки не сломали склад
Три вещи в учётной системе делают обмен возможным, и ни одну из них не заменяет никакая интеграция. Первая — единый пул остатков: одно место, где считается доступное к продаже количество по всем каналам сразу, включая розницу и опт. Вторая — правило распределения этого количества между каналами, потому что показывать один и тот же остаток четырём витринам можно только до определённой глубины запаса. Третья — резерв под отгрузку, который уменьшает доступное количество в момент появления заказа, а не в момент отгрузки.
Все три разобраны подробно в соседних материалах: модели распределения остатка между площадками — в интеграции магазина с площадками, правила резерва и срок его жизни — в разборе резерва товара и доступности. Здесь важно одно: если этих трёх узлов нет, любой обмен будет добросовестно возить на витрины неверное число, и виноват в отменах окажется не API.
Отдельная строка — товар, физически лежащий на складе площадки. Он не входит в доступный остаток и не выгружается ни на эту площадку, ни на другие: управлять им можно только поставками. В учёте это отдельный склад, и заводится он до начала интеграции, а не после первой пересортицы.
Готовый сервис или своя интеграция: три критерия и порог
Готовые сервисы связи с площадками закрывают типовой сценарий за 12 000–35 000 ₽ в месяц и делают это лучше, чем средняя самописная интеграция первого года. Свой слой обмена стоит 450 000–900 000 ₽ разово и 15 000–40 000 ₽ в месяц на сопровождение. Выбор между ними делается по трём критериям, и ни один из них не про «хочется своё».
| Критерий | Готовый сервис подходит | Нужен свой слой |
|---|---|---|
| Набор площадок и схем работы | Крупные площадки, стандартные схемы, один-два склада | Редкая площадка, собственная доставка, несколько юрлиц или складов на одну карточку |
| Своя логика поверх обмена | Остаток и цена берутся из учёта как есть | Комплекты и наборы, приоритеты каналов, свои правила цены и резерва, ограничения по клиентам |
| Ответственность за сверку денег | Достаточно выгрузки отчётов в учёт, разбирает бухгалтерия | Нужна автоматическая раскладка удержаний по видам и себестоимость канала в отчётности |
Порог по объёму считается не по обороту, а по числу заказов в сутки, потому что ручная работа масштабируется именно от него. До 30 заказов в сутки собственная интеграция не окупается почти никогда — берите сервис. От 30 до 150 работает гибрид: сервис возит стандартные контуры, а своя надстройка закрывает то, чего в нём нет. Выше 150 заказов в сутки ручной стык становится дороже собственного слоя, и разработка окупается за год.
Дальше считается честно. Свой слой обмена за 620 000 ₽ снимает 32 300 ₽ ручной работы и примерно половину отмен — ещё 6 900 ₽, но добавляет 25 000 ₽ поддержки вместо 22 000 ₽ подписки. Чистая экономия — 36 200 ₽ в месяц, окупаемость 620 000 ÷ 36 200 = 17 месяцев. Это долго. При 150 заказах в сутки те же строки растут пропорционально объёму: экономия становится 62 300 ₽ в месяц, а окупаемость — около 10 месяцев. Отсюда и берётся порог: не из вкуса, а из точки, где кривая ручных часов пересекает стоимость разработки.
График с двумя осями: по горизонтали число заказов в сутки от 30 до 200, по вертикали срок окупаемости своего слоя обмена в месяцах. Кривая падает слева направо. Отмечены и подписаны три точки: «30 заказов — не окупается», «90 заказов — 17 месяцев», «150 заказов — 10 месяцев». Горизонтальная штриховая линия на отметке 12 месяцев с подписью «граница разумного срока». Слева от точки пересечения зона подписана «готовый сервис», справа — «свой слой обмена». Все подписи по-русски.
Когда своя интеграция не нужна
Есть четыре ситуации, в которых мы отговариваем от собственного слоя обмена, и каждая встречается чаще, чем хотелось бы подрядчикам.
- Меньше 30 заказов в сутки. Ручной перенос занимает час-полтора в день, автоматизация стоит 450 000–900 000 ₽ и не возвращается. Разумный порядок: готовый сервис, порядок в номенклатуре, возврат к вопросу при росте потока в три-четыре раза.
- Номенклатура не в порядке. Если штрихкоды заведены не у всех позиций, артикулы дублируются, а один товар живёт в базе тремя карточками, обмен добросовестно размножит этот беспорядок на трёх площадках. Сначала справочник — потом интеграция. Здесь же полезно навести порядок в самой матрице: как это делается, разобрано в материале об ассортиментной матрице и неликвиде.
- Одна площадка и одна схема работы. Экономика собственного слоя строится на переиспользовании: три адаптера дешевле трёх интеграций. На одной площадке этот эффект отсутствует, и разработка проигрывает сервису по всем статьям.
- Нет человека, который будет смотреть на расхождения. Любой обмен оставляет 1–3 % операций для ручного разбора. Если этих операций никто не разбирает, через квартал данные расходятся настолько, что проще пересобрать остатки инвентаризацией — и тогда деньги за интеграцию потрачены на генератор расхождений.
И последнее. Всё описанное — по состоянию на сентябрь 2026 года. Площадки меняют методы, лимиты, состав отчётов и правила работы несколько раз в год, поэтому любые конкретные значения в проекте берутся из документации на день работ, а не из статьи. Устойчивы здесь только три вещи: задержка есть всегда, отправка не равна приёму, а расхождение между кабинетом и учётом надо не побеждать, а уметь объяснять.
Обмен с площадкой — это не провод, а почта. Письмо доходит, но не мгновенно и не всегда с первой попытки.
