Интеграция: Маркетплейсы + Битрикс24

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

Типовые системы на этом конце: Wildberries, Ozon, Яндекс Маркет, Мегамаркет, Lamoda.

Битрикс24 — CRM и корпоративный портал: сделки, задачи, ленты, телефония. Часто уже используется отделом продаж, поэтому магазин должен отдавать туда заказы и заявки.

Как с ней работать технически: REST API с входящими и исходящими вебхуками, работа с сущностями (лиды, сделки, контакты, товарные позиции). Для облачных тарифов действует ограничение по частоте запросов — синхронизацию делают очередями с ограничителем.

На маркетплейс уходят карточки, цены, остатки и штрихкоды; обратно — заказы и сборочные задания, статусы, отчёты о продажах, комиссиях и логистике.

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

«Маркетплейсы» и «Битрикс24» отвечают за разные участки процесса, поэтому прямой коннектор между ними нужен не всегда — чаще они сходятся в одной из систем контура. CRM не хранит товарные остатки, платежи и чеки — она отвечает за отношения с клиентом. Обмен строим по единому ключу (телефон, e-mail или ID клиента), иначе появляются дубли контактов, а синхронизацию запускаем очередями с ограничителем частоты запросов.

Реализация зависит от того, есть ли у системы открытый API и какие у него лимиты. Если API нет или он ограничен, обмен строим через промежуточный слой: очередь, промежуточную базу или файловый обмен по расписанию с журналом обработки.

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

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

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

Часть ограничений обходится архитектурой (кэш, очередь, разделение каналов обмена), часть — нет: тогда мы предлагаем изменить процесс, а не имитировать его в коде.

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

Сроки обычно определяет не разработка, а согласования: доступы к системе, тестовый контур, договор с провайдером, правила расчёта и требования бухгалтерии. Мы выносим эти пункты в чек-лист подготовки, чтобы они не останавливали работы в середине проекта.

Первый шаг — обследование: смотрим, какие данные уже ведутся, кто владелец каждой сущности и какие ограничения есть у API. Затем делаем прототип обмена на тестовом контуре, проверяем нештатные сценарии (повтор, отмена, частичное выполнение) и только после этого выводим интеграцию в продуктив.

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