Уявіть: ви розробили застосунок для Бітрікс24, пройшли модерацію, опублікували в маркетплейсі. За тиждень приходять скарги — у половини клієнтів не працює синхронізація, застосунок видає 403 на crm.deal.list. Виявляється, тариф «Базовий» не дає прав на CRM, а ви не передбачили перевірку. Або webhook перестав відповідати — обробник відв'язався, дані втрачено. Такі ситуації — наслідок типових помилок, яких можна уникнути на етапі архітектури. Проблема в тому, що типові шаблони та unchecked errors — головна причина відмов при модерації та втрати клієнтів. Ми за 5 років реалізували понад 50 застосунків для маркетплейсу Бітрікс24 — від простих віджетів до multi-tenant рішень. І знаємо, як зробити стабільний продукт, який не підведе клієнтів. Ми спеціалізуємося на проектуванні стійких застосунків, які проходять модерацію з першого разу. Наш досвід дозволяє уникнути пасток, пов'язаних з тарифними обмеженнями та обробкою помилок. Вартість розробки індивідуальна, але інвестиції окупаються за рахунок економії на підтримці та повторних доробках. Замовте консультацію — ми покажемо, як знизити витрати на 20% за рахунок продуманої архітектури.
Які типи застосунків існують?
Вбудовані застосунки (embed) працюють в iframe через placement API. Точки: CRM_LEAD_DETAIL_TAB, TASKS_TASK_VIEW_TAB, CALL_LIST та десятки інших. Віджети вбудовуються через BX24.placement.call() для невеликих дій: кнопка в картці, панель в чаті. Застосунки з власним інтерфейсом відкриваються в окремій вкладці, більше свободи UX, але користувач виходить з контексту. Боти та чат-застосунки використовують imbot.* та imsetting.* методи, мають власний обробник.
Порівняння типів:
| Тип | Точки інтеграції | Складність | Коли вибирати |
|---|---|---|---|
| Вбудоване (embed) | Placement API | Середня | Потрібна робота в контексті CRM, завдань |
| Віджет | BX24.placement.call() | Низька | Маленька дія в інтерфейсі |
| Застосунок з UI | Окрема вкладка | Висока | Вимагається складний інтерфейс |
| Бот/месенджер | imbot., imsetting. | Середня | Автоматизація чатів |
Як працює OAuth 2.0 в застосунках?
Авторизація будується на OAuth 2.0 з кодом авторизації. Флоу:
- Користувач встановлює застосунок → редирект на redirect_uri з code.
- Застосунок обмінює code на access_token та refresh_token через https://oauth.bitrix.info/oauth/token/.
- Access_token живе 1 годину, refresh_token — 180 днів.
- Токени зберігаються у вашій БД, прив'язані до member_id.
Для server-to-server використовуйте grant_type=client_credentials — доступно для застосунків типу «Застосунок». member_id критичний: всі дані в БД партиціонуються по ньому, інакше дані однієї компанії потраплять до іншої.
REST API: робота з даними
Бітрікс24 REST API — не класичний REST. Методи викликаються POST на https://{portal}.bitrix24.ua/rest/{method} з form-data або JSON. Пагінація через start, ліміт 50 записів. Для отримання всіх — цикл з next.
Популярні групи:
- crm.lead., crm.deal., crm.contact., crm.company. — CRM
- tasks.task.*, task.item.list — завдання
- disk.folder., disk.file. — файли
- im.message.add, imbot.message.add — повідомлення
- user.get, user.search — користувачі
- placement.bind — реєстрація точок вбудовування
Батчинг: відправляйте до 50 запитів через batch. Батчинг в 50 разів швидше послідовних запитів.
POST /rest/batch { "halt": 0, "cmd": { "get_deal": "crm.deal.get?id=123", "get_contact": "crm.contact.get?id=456", "get_company": "crm.company.get?id=789" } } Як обробляти webhook'и без втрати даних?
Підпишіться на події через event.bind. При настанні події Бітрікс24 робить POST на handler URL. Важливі деталі:
- Handler повинен відповідати за
5 секунд. - Після 3 невдалих доставок — обробник відв'язується.
- Для важкої обробки використовуйте чергу: прийміть webhook, покладіть в чергу, відповідьте 200, обробіть асинхронно.
Доступні події: ONCRMLEADADD, ONCRMDEALUPDATE, ONTASKUPDATE, ONIMMESSAGECHAT, ONUSERADD та сотні інших.
Розміщення (placements)
Реєстрація placement проводиться при встановленні через placement.bind. Прив'язується до точки інтерфейсу та передає контекст: ID сутності, тип, права користувача.
BX24.placement.getInterface(function(data) { console.log(data); }); Підключіть //api.bitrix24.com/api/v1/ та викличте BX24.init() перед зверненням до API. В iframe використовуйте localStorage або postMessage.
Як обійти тарифні обмеження?
REST-методи доступні не на всіх тарифах. crm.* — з певних планів, telephony.* — з телефонією, tasks.* — з модулем «Завдання». При встановленні перевіряйте доступність через app.info та profile. Явно повідомляйте користувачу, якщо функціональність недоступна. Не допускайте необроблених 403.
Зберігання даних застосунку
Бітрікс24 надає key-value сховище app.option.set/get (ліміт ~32KB). Для серйозних даних потрібна власна БД. Для користувацьких налаштувань — user.option.set/get на стороні порталу.
Терміни розробки
| Тип застосунку | Термін |
|---|---|
| Простий віджет / embed з читанням даних CRM | 2–4 тижні |
| Повноцінне CRM-застосунок з двосторонньою синхронізацією | 6–10 тижнів |
| Месенджер-бот з NLP та контекстом діалогів | 8–12 тижнів |
| Комплексний застосунок з власним UI, webhooks, multi-tenant БД | 12–20 тижнів |
Що входить в роботу
- Аналіз вимог та проектування архітектури
- Налаштування CI/CD та розгортання на вашому сервері
- Документація REST API та опис інтеграції
- Навчання адміністраторів порталу
- Місячна підтримка після релізу
Приклад інтеграції OAuth
Офіційна документація: https://dev.1c-bitrix.ru/rest_help/oauth/Інфраструктура застосунку
Застосунок повинен бути доступний по HTTPS з валідним сертифікатом. Для production: окремий домен, горизонтальне масштабування (токени в Redis/БД), моніторинг webhook-обробників. Логуйте всі виклики REST API, вхідні webhook'и та OAuth-обміни. Правильна архітектура економить до 40% часу на підтримку.
Детальніше про OAuth: Wikipedia.
Зв'яжіться з нами для консультації по вашому проекту. Отримайте попередню оцінку термінів та вартості.