Как связать Next.js с 1C Bitrix и не убить работающую CRM

Почему про это почти не пишут

Я работаю с Next.js несколько лет — маркетплейсы, бизнес-порталы, внутренние системы. И когда в начале года пришёл проект, где нужно было связать современный фронт на Next.js с живой CRM клиента на 1C Bitrix, я сел искать материалы и понял: в рунете про эту связку почти ничего нет.

Если загуглить «Next.js + 1C Bitrix», в выдаче будет в основном две категории материалов: обзорные статьи на русском, которые пересказывают документацию Bitrix, и англоязычные туториалы по интеграции Next.js с абстрактными REST API. Ни те, ни другие не отвечают на реальный вопрос: как интегрировать современный фронт на Next.js с работающей корпоративной CRM на 1C Bitrix так, чтобы при этом не сломать существующие процессы внутри компании.

Причина простая. Next.js — стек, на котором пишут стартапы и западные агентства. 1C Bitrix — инструмент, на котором в России держится значительная часть корпоративных CRM и внутренних систем среднего бизнеса. Пересечение этих двух миров узкое: мало кто делает современный публичный фронт на Next.js поверх внутренней CRM на Bitrix. Поэтому опыт есть только у тех, кто руками прошёл через эту интеграцию на реальном проекте.

У меня такой проект был — маркетплейс недвижимости vsedomatut.ru. Фронт на Next.js 16, PostgreSQL как основная база каталога, двусторонняя синхронизация с 1C Bitrix, где у клиента за год накопились объекты, клиенты и сделки. Останавливать Bitrix было нельзя ни на день — команда продолжала в нём работать, пока мы строили новую платформу.

Ниже — что сработало, что сломалось, и на что обратить внимание, если вы планируете похожую интеграцию.

Контекст рынка: зачем вообще связывать Next.js и Bitrix

Типовая ситуация в российском среднем бизнесе выглядит так. Компания годами работает в 1C Bitrix как в CRM — там клиентская база, воронка сделок, документооборот, задачи менеджеров. Всё это работает. Команда обучена, процессы отлажены.

И в какой-то момент бизнесу нужен публичный сайт. Не лендинг, а полноценный продукт — маркетплейс, каталог с фильтрами, личный кабинет клиента, партнёрский портал. На уровне пользовательского опыта он должен выглядеть как современный SaaS, быстро грузиться, индексироваться поисковиками, работать с мобильных.

Сайт на самом Bitrix сделать можно — у него есть CMS-часть. Но она сильно отстаёт от современных фронтенд-стеков: шаблонная архитектура, ограниченная гибкость, сложности с SSR и performance. Если вы хотите получить загрузку меньше секунды, нормальное SEO и UX, на котором пользователь не уходит — нужен современный фронт.

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

Архитектура: что где живёт

Самая частая ошибка — пытаться сделать Bitrix единственным источником правды и дёргать его API на каждый запрос пользователя с публичного сайта. Это не работает по двум причинам: REST API Bitrix медленный для публичных сценариев, и любая нагрузка на API напрямую бьёт по работе менеджеров внутри CRM.

Работающий подход — разделить слои.

На стороне Next.js живёт всё, что видит публичный пользователь: каталог, фильтры, поиск, карточки объектов, личный кабинет, партнёрская модерация. Данные для этого берутся из собственной базы — у нас это PostgreSQL. Именно эта база — источник данных для публичной части. Next.js с ней работает напрямую через ORM, без оглядки на Bitrix.

На стороне Bitrix остаётся всё, к чему уже привыкла команда: клиентская база, сделки, внутренние задачи, документооборот. Менеджеры работают в Bitrix как работали. Ничего в их интерфейсе не меняется.

Между ними — отдельный слой синхронизации. Не часть Next.js, не часть Bitrix. Отдельный сервис (в нашем случае — Node.js-воркер, который работает по расписанию и по вебхукам), единственная задача которого — переносить данные в обе стороны и разрешать конфликты.

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

Направление синхронизации настраивается по сущностям. У нас было так: объекты недвижимости синхронизируются двусторонне (добавление на сайте партнёром должно прилетать в Bitrix, изменение статуса в Bitrix должно отражаться на сайте). Клиентские заявки идут только в одну сторону — с сайта в Bitrix, потому что работать с клиентом дальше будет менеджер внутри CRM. Справочники (типы домов, районы) идут только из Bitrix на сайт, чтобы не было рассинхрона.

Три подводных камня, которые встретите

Первый — типы данных не совпадают. У Bitrix исторически гибкая типизация: поле «цена» может быть строкой с пробелами и символом рубля, поле «площадь» — строкой с запятой вместо точки. В PostgreSQL, особенно если вы закладываете индексы для быстрой фильтрации, вам нужны строгие типы: numeric, integer, boolean. На маппинге между ними ломается половина первых синхронизаций.

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

Второй — дубли при параллельной правке. Сценарий: партнёр добавляет объект через сайт, синхронизатор его подхватывает и создаёт запись в Bitrix. Одновременно менеджер внутри Bitrix создаёт тот же объект вручную, потому что ему позвонил тот же партнёр по телефону. Через несколько минут в базе два одинаковых объекта: один создан через API, второй — через интерфейс менеджера.

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

Третий — таймауты API Bitrix на больших выборках. REST API Bitrix плохо справляется с запросами типа «отдай все объекты». На большой базе такой запрос падает по таймауту или возвращает частичный результат без явного признака, что он частичный.

Правильный паттерн — пагинированные запросы с фиксированным размером страницы (у нас 50 записей) и retry-логикой на каждый запрос. Плюс — инкрементальная синхронизация вместо полной: после первого полного прогона воркер дёргает Bitrix только за изменёнными с последнего прогона записями. Это уменьшает нагрузку на порядок и убирает большую часть проблем с таймаутами.

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

Чек-лист готовности к интеграции

Прежде чем начинать проект, где Next.js должен говорить с 1C Bitrix, проверьте несколько вещей.

Есть ли у вас доступ к REST API Bitrix. Звучит очевидно, но в половине проектов выясняется, что нужные права не выданы, а за ними — отдельный разговор с администратором или вендором Bitrix.

Понимаете ли вы, какие сущности нужно синхронизировать и в каком направлении. Не «всё со всем», а конкретно: вот эти сущности двусторонне, вот эти только с сайта в CRM, вот эти только из CRM на сайт. Если этот список не зафиксирован до начала работы — границы проекта поплывут.

Есть ли в вашей модели данных однозначный идентификатор объекта с обеих сторон. Без него вы не сможете надёжно сопоставлять записи и ловить дубли.

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

Есть ли у вас отдельный мониторинг синхронизатора. Воркер, который молча перестал работать, — худший сценарий из возможных. Нужны алерты: на отсутствие успешных проходов за N минут, на резкий рост количества ошибок, на рост очереди необработанных изменений.

Итог

Next.js и 1C Bitrix — не враги, если не пытаться сделать из них одну систему. Они хорошо работают вместе, когда у каждого своя зона ответственности: Bitrix отвечает за внутренние процессы и CRM, Next.js — за публичный продукт и пользовательский опыт, а между ними — отдельный слой синхронизации, который разрешает конфликты и не даёт нагрузке одного влиять на работу другого.

Если у вас уже есть Bitrix с живыми процессами и вам нужен современный сайт поверх него — не начинайте с миграции. Начните с интеграции. Это дешевле, быстрее и обратимо.

Проект, на котором это собрано: вседоматут.рф

Яков Радченко, основатель ETERN8. Next.js, маркетплейсы, бизнес-порталы. Пишу на VC о том, что сам прошёл руками.