Интеграция двух 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.