Документація живе в 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 та тестуємо на надлишкових навантаженнях. Замовте консультацію — ми проаналізуємо вашу схему даних і запропонуємо оптимальну архітектуру інтеграції. Зв'яжіться з нами, щоб обговорити деталі вашого проєкту.