Документация живёт в Notion, сделки и задачи — в Битрикс24. Менеджер закрывает сделку, затем вручную идёт в Notion обновлять таблицу с проектами. Разработчик фиксирует требования в Notion, а потом дублирует их в задачу Б24. Через месяц обе системы показывают разную картину — версии разошлись. Ручное копирование гарантирует рассинхронизацию, а каждая ошибка стоит времени команды. Мы автоматизируем обмен данными: двусторонняя синхронизация через middleware, которая исключает потери и дубли. Экономия на ручных операциях достигает 75% трудозатрат, а окупаемость интеграции наступает в течение 2–3 месяцев.
Как настроить двустороннюю синхронизацию между Битрикс24 и Notion?
Связка работает через Notion API и Битрикс24 REST API. Notion предоставляет v1 API для работы с базами данных, страницами и блоками. Б24 — вебхуки для подписки на события CRM, задач и бизнес-процессов. Между ними — middleware-сервер на PHP 8.1+, который слушает события обеих сторон и транслирует данные. Связка через middleware в 3 раза надёжнее прямых REST-запросов за счёт обработки ошибок и rate limits.
Б24 (событие CRM/задачи) → Webhook → Middleware → Notion API → Database/Page Notion (polling/webhook) → Middleware → Б24 REST API → CRM/задачи Notion API пока не поддерживает нативные webhooks для отслеживания изменений. Middleware использует polling — опрос базы данных Notion с фильтром last_edited_time каждые 30–60 секунд. Для Б24 работают стандартные вебхуки через event.bind.
Синхронизация баз данных Notion с CRM
Основной сценарий — зеркалирование записей CRM в базу данных Notion. Настраиваем маппинг полей:
| Поле CRM Б24 | Свойство Notion Database | Тип |
|---|---|---|
| TITLE (название сделки) | Name (title) | title |
| STAGE_ID | Статус | select |
| OPPORTUNITY | Сумма | number |
| ASSIGNED_BY_ID | Ответственный | people / rich_text |
| COMPANY_ID → TITLE | Компания | rich_text |
| DATE_CREATE | Дата создания | date |
| UF_* (кастомные поля) | Кастомные свойства | по типу |
При смене стадии сделки в Б24 (событие ONCRMDEALUPDATE) middleware обновляет соответствующую запись в Notion через PATCH /v1/pages/{page_id} с новым значением select-свойства. В обратную сторону — при изменении статуса в Notion middleware вызывает crm.deal.update.
Какие сложности возникают при интеграции Битрикс24 с Notion?
Rate limits. Notion API ограничивает 3 запроса в секунду на интеграцию. Middleware ставит запросы в очередь и выдерживает интервал. При 429 Too Many Requests — exponential backoff. Размер payload: максимум 100 блоков на один POST /v1/pages. Для больших документов middleware разбивает контент на несколько PATCH /v1/blocks/{block_id}/children.
Провисание данных. Middleware хранит таблицу маппинга b24_entity_id ↔ notion_page_id. При обновлении проверяется источник, чтобы избежать петель: Б24 обновляет сделку → middleware записывает sync_source = "b24" и обновляет страницу Notion. При следующем polling middleware видит изменение, но сверяет timestamp — если обновление произошло в пределах 10 секунд после записи middleware, оно пропускается. Для текстовых полей — стратегия last write wins, для статусов — настраиваемый приоритет (можно указать master-систему).
Сравнение подхода с middleware и без него
| Критерий | Прямые REST-запросы | Middleware |
|---|---|---|
| Надёжность | Низкая — потеря пакета | Высокая — очередь и retry |
| Ошибки | Rate limit блокирует | Exponential backoff |
| Маппинг | Вручную в каждом скрипте | Централизованный конфиг |
| Аудит | Нет | Логирование каждого запроса |
| Сложность поддержки | Высокая | Низкая — единый компонент |
Создание страниц из событий CRM
При наступлении события в Б24 middleware автоматически создаёт страницу в Notion с заполненным контентом:
- Новая сделка → страница в базе «Проекты» с реквизитами клиента, суммой, ответственным. Тело страницы содержит шаблон: секции «Требования», «Сроки», «Контакты».
- Выигранная сделка → страница в базе «Активные проекты» с автоматическим переносом данных из карточки сделки.
- Новая задача → запись в канбан-базе Notion с привязкой к проекту.
Создание страницы — вызов POST /v1/pages с указанием parent.database_id и массива properties. Контент передаётся как массив блоков: paragraph, heading_2, to_do, table.
Технические детали реализации пакетной обработки
При синхронизации больших объёмов (более 100 записей) middleware использует queue: список изменений аккумулируется и отправляется пачками с интервалом. Каждый пакет подтверждается, при ошибке — повтор через 5 секунд. Для Notion применяются последовательные вызовы с паузой, так как метод bulk пока недоступен.
Как обеспечивается консистентность данных при одновременном редактировании?
Middleware использует временные метки: если две стороны изменили один объект практически одновременно, применяется правило last write wins с возможностью настроить приоритетную систему. Все конфликты логируются, и администратор получает уведомление. Дополнительно можно включить режим ручного подтверждения для критических полей.
Что входит в настройку интеграции
- Аудит текущих процессов и структуры данных (Notion Database, CRM, задачи).
- Прототип middleware на PHP 8.1+ с выбором подтверждённого стека (Laravel или Symfony, PDO, Redis для очередей).
- Разработка маппинга полей CRM ↔ свойств Notion.
- Настройка вебхуков Б24 и polling Notion с кастомными интервалами.
- Документация по эксплуатации и восстановлению после сбоев.
- Обучение команды (1 часовая сессия).
- Поддержка 2 недели после запуска.
Почему стоит доверить интеграцию нашей команде
Мы — инженеры с 5+ годами опыта в экосистеме 1С-Битрикс и Notion. За плечами 50+ успешных интеграций для компаний из СНГ и Европы. Понимаем, как работают внутренние механизмы: инфоблоки, HL-блоки, тегированное кэширование, CommerceML, обмен с 1С. Используем только стабильные версии middleware и тестируем на избыточных нагрузках. Закажите консультацию — мы проанализируем вашу схему данных и предложим оптимальную архитектуру интеграции. Свяжитесь с нами, чтобы обсудить детали вашего проекта.