Розробка інтеграції Bitrix24 з маркетплейсами
Інтеграція Bitrix24 з Ozon, Wildberries або Яндекс Маркет потрібна компаніям, які використовують CRM для управління клієнтами і хочуть бачити замовлення з маркетплейсів в одному місці. Типова проблема: менеджер працює в Bitrix24, але дивиться дані про замовлення в особистому кабінеті маркетплейсу в іншій вкладці. Інтеграція усуває цей розрив.
Що інтегрується й навіщо
Bitrix24 — це насамперед CRM і інструменти командної роботи, а не повноцінна платформа e-commerce. Тому інтеграція з маркетплейсами вирішує конкретні завдання:
Замовлення → CRM. Кожне замовлення з маркетплейсу створюється як угода (crm.deal.add) або лід в Bitrix24. Менеджер бачить замовлення, обробляє його, дзвонить клієнтові — все всередині CRM. Статуси синхронізуються в обидва боки.
Сповіщення. При надходженні нового замовлення або зміні його статусу — сповіщення відповідальному менеджеру через im.notify.system.add або через задачу/угоду в CRM.
Аналітика. Дані про продажі з маркетплейсів потрапляють у звіти CRM. Можна бачити лійку за джерелами, порівнювати маркетплейси один з одним.
Комунікації. Повідомлення від покупців на маркетплейсі (там, де маркетплейс надає API для кореспонденції, як Ozon) — в стрічці активності угоди в Bitrix24.
Архітектура: проміжковий сервіс
Bitrix24 і маркетплейс — два незалежних API. Прямого способу з'єднати їх немає. Потрібен проміжний сервіс (middleware), який:
- Слухає webhook'и від маркетплейсу (нові замовлення, зміни статусів)
- Переводить дані маркетплейсу в формат REST API Bitrix24
- Створює/оновлює сутності в Bitrix24 через REST
- В зворотному напрямку: при зміні статусу угоди в Bitrix24 — оновлює статус замовлення на маркетплейсі
Цей сервіс — окремий додаток, який можна:
- Розгорнути як власний сервер (PHP/Node.js/Python)
- Оформити як додаток для маркетплейсу Bitrix24 (тоді він доступний іншим користувачам)
- Використовувати готові no-code коннектори типу n8n/Make (для простих сценаріїв)
Для серйозного навантаження (сотні замовлень на день) потрібен власний сервіс з чергою й логікою retry.
Маппінг даних: угода vs замовлення
Дані замовлення на маркетплейсі не збігаються з полями угоди в Bitrix24 CRM. Потрібен маппінг:
| Поле замовлення маркетплейсу | Поле в Bitrix24 CRM |
|---|---|
| order_id | UF_CRM_DEAL_* (користувацьке поле) або TITLE |
| buyer name / email | crm.contact (пошук або створення) |
| product list | crm.deal.productrows.set |
| total_price | OPPORTUNITY |
| status | STAGE_ID (маппінг статусів) |
| marketplace name | SOURCE_ID або користувацьке поле |
| created_at | DATE_CREATE |
| delivery address | CONTACT.ADDRESS або користувацьке поле |
Маппінг статусів — окремо завдання. Статуси маркетплейсу й стадії лійки Bitrix24 потрібно явно зіставити в конфігурації інтеграції.
Робота з контактами: дедублікація
Один покупець може розміщувати замовлення з різних маркетплейсів і прямо на сайті. При створенні контакту в Bitrix24 потрібно перевіряти дублі через crm.duplicate.find.by.comm (пошук за email/телефоном). Якщо контакт вже існує — прив'язати угоду до нього, а не створювати нового.
На маркетплейсах персональні дані покупців часто приховані (WB не розкриває email, Ozon — тільки за запитом). У такому разі зовнішній ID покупця на маркетплейсі використовується як ідентифікатор, що зберігається у користувацькому полі контакту.
Синхронізація статусів
Зворотна синхронізація (Bitrix24 → маркетплейс) потрібна, коли менеджер змінює стадію угоди й це повинно відображатися в кабінеті маркетплейсу. Це працює через:
- Підписку на подію
ONCRMDEALUPDATEв Bitrix24 - При зміні
STAGE_ID— перевірку, чи є угода замовленням з маркетплейсу (за користувацьким полемUF_MARKETPLACE_SOURCE) - Виклик відповідного API маркетплейсу для оновлення статусу
Для WB це /api/v3/orders/{orderId}/status, для Ozon — /v3/posting/fbs/status/set. Не всі статуси доступні для зміни ззовні — маркетплейси дозволяють переводити замовлення тільки в певні статуси з певних станів.
Товарний каталог: потрібна ли синхронізація
Деякі компанії хочуть не тільки замовлення, але й синхронізацію каталогу: товари з Bitrix24 (або з сайту на Bitrix) мають автоматично завантажуватися на маркетплейс. Це окремо, більш об'ємна завдання (див. інтеграцію 1С-Bitrix з маркетплейсами).
У контексті Bitrix24 каталог товарів (crm.product.*) часто використовується для CRM-продуктів, а не як повноцінний e-commerce каталог. Якщо каталог ведеться саме там — синхронізація можлива, але вимагає нетривіального маппінгу на атрибути маркетплейсу.
Строки розробки
| Сценарій | Строк |
|---|---|
| Один маркетплейс, тільки замовлення → ліди/угоди в CRM | 3–5 тижнів |
| Один маркетплейс, двостороння синхронізація статусів | 5–8 тижнів |
| Два маркетплейси, спільна інтеграція з CRM й сповіщеннями | 8–12 тижнів |
| Повний цикл: замовлення + каталог + аналітика, кілька маркетплейсів | 14–20 тижнів |
Готові рішення й їх обмеження
На маркетплейсі Bitrix24 є кілька додатків-коннекторів для Ozon і WB. Вони покривають базові сценарії й коштують значно менше, ніж розробка з нуля. Обмеження: фіксована логіка маппінгу, неможливість додати нестандартні поля, залежність від оновлень вендора додатку.
Кастомна розробка виправдана, коли: специфічна логіка обробки замовлень, інтеграція з кількома системами одночасно (маркетплейс + 1С + склад), вимоги до надійності вищі, ніж може забезпечити готовий додаток.