Интеграция Битрикс с маркетплейсами: сравниваем четыре схемы

Магазин на 1С-Битриксе, около 3 000 товаров, витрина работает, заказы идут. Выход на Ozon и Wildberries кажется технически простым: YML-фид для Яндекс Маркета уже настроен, значит остальным отдадим то же самое. Не отдадим. Ни Ozon, ни Wildberries прайс-листами в формате YML не торгуют: карточки там заводятся через кабинет или через API контента, а остатки и заказы ходят только по API. Фид закрывает одну задачу из четырёх, и дальше начинается выбор схемы обмена, которую придётся поддерживать годами. Ниже — про «1С-Битрикс: Управление сайтом» редакций «Малый бизнес» и «Бизнес» версий 23.x–24.x; на 20.x часть настроек лежит в других разделах админки.

Четыре потока обмена, а не один

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

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

Фидовые механики (YML для Яндекс Маркета, XML-автозагрузка для Avito) закрывают первые два потока и то не полностью. Остатки в режиме FBS и заказы на всех крупных площадках идут через API. Требования к фидам и состав методов API площадки меняют регулярно — конкретные поля и лимиты смотрите в справке для продавцов, а не в чьей-то статье годичной давности.

Схема 1. Готовый модуль из Маркетплейса 1С-Битрикс

В каталоге решений 1С-Битрикс есть модули под каждую крупную площадку: ставятся в админке, добавляют свою страницу настроек, маппинг свойств и агенты обмена. Для магазина, который уже живёт на Битриксе и держит в нём товары и остатки, это самый короткий путь: от установки до первых выгруженных карточек — часы, а не недели.

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

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

Схема 2. Внешний сервис-агрегатор

SaaS-прослойка между вашим каталогом и кабинетами площадок. Битрикс в этой схеме отдаёт данные одним способом (фид, выгрузка, API магазина), а дальше сервис сам раскладывает их по площадкам и тянет заказы обратно.

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

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

Схема 3. Обмен через 1С (УТ или ERP)

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

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

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

Схема 4. Своя интеграция на API площадок

Собственный модуль в Битриксе: очередь задач, обработчики событий каталога и заказа, свои таблицы соответствий, логи обмена. Берут её, когда логика не влезает в чужие настройки — несколько складов с разными приоритетами, свои правила ценообразования по площадкам, сборные комплекты, резерв под B2B-заказы.

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

Интеграция стоит не столько денег, сколько одного честного ответа: где у вас лежит правда об остатке. Пока ответов два, любая схема будет продавать то, чего нет.

Сравнение схем

Когда что выбирать: рабочие критерии

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

1. Посчитайте площадки. Одна — берите модуль под неё и не усложняйте. Три и больше — либо агрегатор, либо своя интеграция с общим пулом остатков. Три независимых модуля почти гарантированно начнут перепродавать остаток.
2. Найдите источник правды по остатку. Если это 1С — вешайте площадки на 1С и не делайте Битрикс лишним звеном в цепочке. Если остатки ведутся в Битриксе через «Торговый каталог» и склады — обмен идёт из Битрикса.
3. Оцените глубину остатка. Товар в единственном экземпляре (мебель, украшения, вторичка) — сначала решайте задачу резерва и скорости, потом выбирайте инструмент. Склад с запасом в десятки штук терпит и обмен раз в час.
4. Проверьте уникальность логики. Сможете описать правила остатков и цен в полях настроек готового модуля — берите готовое. Если в описании появляются слова «кроме случаев, когда» — вы в зоне своей разработки.
5. Посмотрите на год вперёд, а не на запуск. Сравнивайте лицензию или абонентку с зарплатной стоимостью поддержки своего кода, а не с ценой его написания.

Что ломается в проде

Двойные продажи на последнем товаре

Классика: заказ пришёл на сайт, остаток обновился в Битриксе, но до площадки доехал через 20 минут. За это время товар купили ещё раз. Лечится не ускорением обмена до бесконечности, а буфером: часть остатка не отдаётся площадкам вовсе. Либо резервом на стороне источника правды, если схема это позволяет.

Агенты, которые запускаются «на хите»

Почти все обмены в Битриксе висят на агентах. По умолчанию они срабатывают на посещении сайта, и на магазине с низким трафиком ночью обмен просто не идёт: нет посетителей — нет запуска. Агенты переводятся на cron стандартным средством ядра (скрипт cron_events.php в модуле main) с одновременным отключением запуска на хите в настройках главного модуля. Точную строку crontab и имя константы для dbconn.php сверьте в документации под вашу версию — формулировки в интерфейсе и в примерах отличались между версиями.

Разъехавшиеся артикулы

Самая дорогая в разборе проблема. Пока соответствие «товар в Битриксе — товар на площадке» живёт в свойстве инфоблока, которое кто-то правит руками, обмен будет периодически записывать остаток не тому SKU. Отдельная таблица или служебный инфоблок соответствий с идентификаторами площадки, историей изменений и запретом на ручное редактирование снимает почти весь класс ошибок.

Лимиты API и молчаливые отказы

У каждой площадки свои ограничения на частоту запросов и размер пакета. Обмен, который при 500 товарах работал, на 5 000 начинает получать отказы — и если ответы площадки не логируются, вы узнаете об этом из претензии покупателя. Логируйте каждый обмен с кодом ответа и телом ошибки, храните лог хотя бы неделю.

Заказы без идемпотентности

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

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

Что делать дальше

Независимо от выбранной схемы, первым делом заведите справочник соответствий товаров и сделайте его единственным местом, где эта связь хранится. Затем включите логирование обменов и поставьте один простой алерт: «последний успешный обмен остатками был больше N минут назад». Этот показатель и есть главная метрика интеграции — не количество выгруженных карточек, а лаг остатка. Померяйте его на живом магазине в будний день, сравните с глубиной склада по ходовым позициям, и станет видно, хватает ли вам текущей схемы или пора переходить к следующей.

FBS (Fulfillment by Seller) — схема, при которой товар лежит на складе продавца, а площадка передаёт ему заказ на сборку и забирает отправление. Именно в ней критична скорость обмена остатками: при FBO товар уже на складе маркетплейса и остаток считает он.

Агент в 1С-Битриксе — периодическая задача ядра. Запускается либо при посещении сайта, либо по расписанию через cron; на обменах с внешними системами второй вариант практически обязателен.