На главную

Интеграция двух Bitrix24 между собой

Обновлено 17 августа 2026

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

1. Три способа связать порталы

Вебхуки + REST напрямую. Свой скрипт или middleware между порталами: входящие вебхуки на чтение-запись, исходящие — как триггер. Максимум контроля, минимум готового: очереди, повтор ошибок, конфликты, файлы и мониторинг пишете сами. Оправдано для узкого одностороннего переноса, который не жалко поддерживать.

Приложение Маркетплейса. Готовый продукт ставится на оба портала штатной установкой, использует OAuth-авторизацию (пароли администратора никому не передаются) и получает события портала как зарегистрированное приложение. Инфраструктура обмена — забота вендора. Подходит для постоянной двусторонней синхронизации.

Коробочный модуль. Если портал self-hosted (коробка), на его сервере можно разместить модуль, который выполняет запросы внутри процесса портала — внешний REST-транспорт с его лимитами из цепочки исчезает. Это дополнение ко второму способу, а не замена: облачная сторона всё равно работает через REST.

Когда какой оправдан: разовый перенос или узкий односторонний поток — руками; постоянный двусторонний обмен — приложение; высоконагруженная коробка — приложение + коробочный модуль.

2. Ограничение облачного REST: ~2 запроса в секунду

Главная константа, вокруг которой проектируется любая интеграция с облачным Bitrix24: портал принимает примерно 2 REST-запроса в секунду. Это бюджет всего портала, его делят все интеграции сразу — телефония, боты, отчёты и ваша синхронизация.

Из этого следует:

  • обмен обязан уметь ждать и дозировать запросы, а не ретраить в лоб — иначе портал начнёт отдавать ошибки лимита всем;
  • «прочитать всё и сравнить» — дорогая операция; нужен инкрементальный обход (по дате изменения) и батчи;
  • чем больше проектов и порталов в связке, тем важнее видеть расход квоты, а не узнавать о его исчерпании по жалобам.

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

3. События портала: что дают и чего от них ждать нельзя

События (event.bind, онлайн-вебхуки) — способ узнать об изменении за секунды вместо минут опроса. Но у них два свойства, которые надо принять на уровне архитектуры:

  • в payload нет данных — только ID изменённого объекта: значения полей всё равно надо читать через REST;
  • доставка не гарантируется и не повторяется — недоступный приёмник, сбой сети, отсеянное приложение — и событие пропало молча.

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

4. Коробочный Bitrix24: почему ограничение снимается

На коробке весь код портала работает на вашем сервере. Модуль, размещённый рядом (например, Local App в BIC), выполняет операции внутри процесса портала: без внешнего HTTP-запроса на каждый вызов, без облачной квоты, со скоростью, ограниченной только железом. Для больших связок (много проектов, тяжёлые файлы) это основной способ ускорить обмен. Требования: доступ к серверу портала для установки и подписанный канал между модулем и платформой обмена — у BIC это HMAC-подпись каждого запроса с ротацией ключей.

5. Чек-лист выбора

  • Направление: нужен экспорт в одну сторону или настоящий двусторонний обмен?
  • Объекты: только поля задач — или ещё вложения, чек-листы, комментарии, переписки?
  • Порталы: оба облачных, оба коробочных, смешанная связка? Сколько клиентских порталов будет через год?
  • Квота: кто ещё расходует REST-лимит порталов и как вы увидите его исчерпание?
  • Отказоустойчивость: что происходит при потерянном событии, недоступном портале, одновременной правке?
  • Управляемость: как ставить обмен на паузу, как отключать, что остаётся после отключения?
  • Стоимость владения: цена решения плюс чьё время уходит на поддержку самописного кода.

Смотрите также: Как синхронизировать задачи между двумя порталами Bitrix24, BIC и альтернативы, тарифы.

Не нашли ответа — напишите в поддержку: info@bic-24.ru.