Інтеграція 1С-Бітрікс з CRM Бітрікс24
Ми стикаємося з цим щодня: інтернет-магазин на 1С-Бітрікс приймає замовлення, а відділ продажів працює в Бітрікс24 CRM. Менеджери вручну переносять дані між системами — втрачають замовлення, дублюють контакти, не бачать історію клієнта. Готове рішення — REST API + вебхуки між двома продуктами одного вендора, але налаштувати його правильно складніше, ніж здається. Наш досвід показує: автоматизація через REST API в 10 разів скорочує час на ручне перенесення даних і виключає помилки. Економія на ручній праці сягає 80% — для магазину з 500 замовленнями на місяць це еквівалентно 30 годинам роботи менеджера. У цій статті розберемо ключові технічні аспекти: вибір методів, мапінг статусів, обробку конфліктів та масштабування через чергу.
Які методи REST API потрібні для інтеграції?
Бітрікс24 надає REST API через OAuth 2.0 або вхідні вебхуки. 1С-Бітрікс спілкується з ним через модуль bitrix24connector (якщо встановлено) або безпосередньо через \Bitrix\Main\Web\HttpClient. Ключові методи:
| Метод Бітрікс24 | Призначення |
|---|---|
crm.lead.add |
Створення ліда з форми сайту |
crm.contact.add / crm.contact.update |
Створення/оновлення контакту |
crm.deal.add / crm.deal.update |
Створення/оновлення угоди із замовлення |
crm.deal.productrows.set |
Прив'язка товарних позицій до угоди |
crm.company.add |
Створення компанії (для B2B) |
crm.activity.add |
Додавання активності (дзвінок, лист) |
Як налаштувати двосторонню синхронізацію без конфліктів?
Одностороння передача (сайт → CRM) реалізується швидко. Проблеми починаються при двосторонній: менеджер змінює статус угоди в Бітрікс24 → сайт має оновити статус замовлення. Одночасно клієнт на сайті може змінити замовлення → CRM має оновити угоду.
Кейс. Інтернет-магазин будматеріалів, 200–300 замовлень на добу. Після запуску двосторонньої синхронізації через 3 дні з'ясувалося: статуси замовлень «гуляють» — замовлення, оплачене на сайті, поверталося в статус «новий» із CRM. Причина: вебхук із Бітрікс24 приходив пізніше події на сайті, перезаписував статус без перевірки пріоритету.
Рішення — 'поле-джерело правди' (source_system) у мапінгу статусів:
// При отриманні вебхука з Б24 — перевіряємо мітку часу $localOrder = CSaleOrder::GetByID($orderId); $localUpdated = strtotime($localOrder['DATE_UPDATE']); $b24Updated = strtotime($webhook['data']['FIELDS']['DATE_MODIFY']); if ($b24Updated > $localUpdated) { // Оновлюємо замовлення на сайті CSaleOrder::StatusOrder($orderId, $newStatus); } Що таке мапінг статусів і чому він важливий?
Статуси замовлень у 1С-Бітрікс зберігаються в b_sale_status, статуси угод Бітрікс24 — у стадіях воронки (crm.status.list). Мапінг — не взаємно однозначний: у Бітрікс24 може бути 10 стадій, на сайті — 5 статусів. Створюємо таблицю відповідності, яка зберігається в користувацькій таблиці або в налаштуваннях модуля.
| Статус замовлення (сайт) | Стадія угоди (Б24) |
|---|---|
| N (новий) | NEW |
| P (оплачений) | WON |
| F (доставлений) | WON |
| C (скасований) | LOSE |
| D (доставляється) | EXECUTING |
Якщо у вас кастомні статуси, наприклад "очікує комплектації" або "резерв", їх потрібно додати як додаткові стадії у воронку Бітрікс24. Ми використовуємо метод crm.status.add для створення нових статусів, після чого зв'язуємо їх через мапінг.
Чому черга запитів критична для надійності?
REST API Бітрікс24 має rate limit: 2 запити на секунду на хмарний тариф. При сплеску замовлень прямий синхронний виклик упреться в ліміт. Використання черги в 5 разів знижує кількість помилок порівняно з синхронними викликами. Правильна архітектура — черга:
- Подія на сайті (
OnSaleOrderSaved) поміщає задачу в таблицю черги. - Агент Бітрікса кожні 30 секунд обробляє чергу порціями по 2 запити/сек.
- При помилці запис залишається в черзі зі збільшеним лічильником спроб (max 5).
Додатково ми інтегруємо моніторинг: якщо черга забивається більш ніж на 1000 елементів, спрацьовує алерт. Це дозволяє вчасно помітити проблеми з мережею або API.
Як виконується інтеграція 1С-Бітрікс з CRM Бітрікс24?
Розберемо процес по кроках. Спочатку аналізуємо поточні бізнес-процеси: які сутності потрібно синхронізувати, які статуси використовуються, який обсяг даних. Потім проектуємо архітектуру — обираємо методи REST API, визначаємо мапінг полів. Реалізуємо обробники подій на сайті та налаштовуємо вебхуки в Бітрікс24. Після цього налаштовуємо чергу та механізм повторних спроб. Тестування включає сценарії конфліктів, перевищення лімітів та відмов. На завершення — документація та навчання.
| Етап інтеграції | Трудозатрати |
|---|---|
| Налаштування OAuth / вебхуків | 2–4 год |
| Мапінг полів і статусів | 4–6 год |
| Розробка обробників подій | 8–12 год |
| Реалізація черги та обробки помилок | 6–10 год |
| Двостороння синхронізація статусів | 6–10 год |
| Тестування та налагодження | 8–12 год |
Синхронізація товарного каталогу
Якщо в Бітрікс24 використовується каталог (crm.product.*), важливо синхронізувати його з каталогом сайту. Інакше в угоді будуть «ручні» позиції без прив'язки до номенклатури. Метод crm.deal.productrows.set приймає масив позицій з PRODUCT_ID — ID товару в каталозі Бітрікс24.
Стратегія: при створенні товару на сайті через подію OnAfterIBlockElementAdd автоматично створюємо/оновлюємо запис у Бітрікс24 через crm.product.add. XML_ID зберігається як зовнішній ідентифікатор для дедуплікації. Так ви уникаєте дублювання номенклатури.
Що входить у роботу і коли окупається
Ми надаємо повний комплект: детальна документація з архітектури інтеграції, налаштовані доступи до REST API та вебхуків, навчання менеджерів роботі з оновленою CRM, а також гарантійна підтримка протягом 30 днів після здачі. Всі роботи виконують сертифіковані спеціалісти з досвідом понад 10 років.
Інтеграція окупається за 1–2 місяці за рахунок скорочення ручної праці. Оцінимо ваш проект за 2 години — зв'яжіться з нами для консультації. Отримайте консультацію по вашому проекту прямо зараз.
Детальніше про REST API Бітрікс24 читайте в офіційній документації.