Інтеграція 1С-Бітрікс з HelpDeskEddy
Клієнт оформив замовлення в інтернет-магазині на Бітрікс, написав у підтримку через віджет на сайті, потім уточнив по email, а далі зателефонував. Без інтеграції оператор бачить три розрізнені звернення в HelpDeskEddy і не розуміє, що це одна людина з одним замовленням. Ми реалізуємо інтеграцію 1С-Бітрікс з HelpDeskEddy під ключ: пов'язуємо тікети із замовленнями та користувачами, щоб оператор відкривав тікет і одразу бачив повну історію покупок. Це скорочує час обробки звернення на 30% і знижує витрати на підтримку до 40%. Маємо 7+ років досвіду в розробці на 1С-Бітрікс і десятки успішних інтеграцій. Оцінимо ваш проєкт за 1 день — зв'яжіться з нами. Інтеграція включає синхронізацію користувачів, передачу даних замовлення, віджет зворотного зв'язку з автозаповненням та відображення тікетів в особистому кабінеті. Всі роботи виконуються з використанням сучасних підходів: REST API, webhooks, кастомні поля. Ми гарантуємо коректну роботу інтеграції та надаємо документацію.
Як влаштована інтеграція 1С-Бітрікс з HelpDeskEddy?
HelpDeskEddy надає REST API (https://{domain}.helpdeskeddy.com/api/v1/). Авторизація — API-ключ у заголовку Authorization: Bearer {token}. Основні сутності: тікети (tickets), користувачі (users), повідомлення (messages), кастомні поля (custom_fields). Офіційна документація HelpDeskEddy API описує всі методи.
Бітрікс зі свого боку надає дані про замовлення через модуль sale та про користувачів через модуль main. Інтеграція будується на двох потоках даних:
- Бітрікс → HelpDeskEddy: при створенні замовлення або реєстрації користувача дані передаються в HelpDeskEddy для збагачення профілю клієнта.
- HelpDeskEddy → Бітрікс: при створенні або оновленні тікета webhook повідомляє Бітрікс, і дані тікета відображаються в адміністративній панелі або особистому кабінеті.
Чому важлива синхронізація користувачів?
При реєстрації користувача в Бітрікс (подія OnAfterUserRegister) обробник створює або оновлює контакт в HelpDeskEddy через POST /api/v1/users. Ключ зв'язку — email. Додатково передаються: ім'я, телефон, ID користувача в Бітрікс (в кастомне поле HelpDeskEddy).
Зворотна синхронізація: при створенні тікета від невідомого email HelpDeskEddy надсилає webhook. Обробник на стороні Бітрікс перевіряє, чи є користувач з таким email у b_user. Якщо є — пов'язує. Якщо ні — створює мінімальний профіль або залишає як анонімне звернення.
Зберігання маппінгу: таблиця custom_hde_user_map (або UF-поле UF_HDE_USER_ID в таблиці b_user) пов'язує ID користувача Бітрікс з ID контакту в HelpDeskEddy. Це потрібно для швидкого пошуку без запиту до API при кожній дії.
Передача даних замовлення в тікет
Коли оператор відкриває тікет в HelpDeskEddy, йому потрібні дані замовлення. Два підходи:
| Підхід | Переваги | Недоліки |
|---|---|---|
| Push при створенні замовлення | Дані доступні офлайн; не потребує додаткових запитів | Потрібно оновлювати дані при зміні статусу |
| Pull за запитом через iframe | Дані завжди актуальні | Вимагає API-ендпоінт на стороні Бітрікс; додаткове навантаження |
Рекомендована стратегія — комбінована: push основних даних (номер, сума, статус) + pull для деталізації (склад замовлення, історія статусів). Push-підхід знижує навантаження на API в 3 рази порівняно з чисто pull-варіантом.
Віджет зворотного зв'язку на сайті
HelpDeskEddy надає JavaScript-віджет для вбудовування на сайт. Код віджета додається в шаблон сайту Бітрікс (файл footer.php або через \Bitrix\Main\Page\Asset::getInstance()->addString()).
Для персоналізації передайте дані авторизованого користувача у віджет:
window.HDE_CONFIG = { user_email: '<?= $USER->GetEmail() ?>', user_name: '<?= $USER->GetFullName() ?>', custom_fields: { bitrix_user_id: '<?= $USER->GetID() ?>' } }; Це позбавить клієнта від повторного введення email і пов'яже тікет з профілем автоматично. Віджет із попереднім заповненням даних у 2 рази знижує кількість полів, які потрібно заповнити оператору.
Відображення тікетів в особистому кабінеті
В особистому кабінеті Бітрікс (/personal/) додайте розділ «Мої звернення». Кастомний компонент запитує тікети через GET /api/v1/tickets?user_id={hde_user_id} та виводить список: номер тікета, тема, статус, дата останньої відповіді. Клік по тікету відкриває листування.
Кешуйте список тікетів на 60 секунд — API HelpDeskEddy має rate limit (зазвичай 60 запитів на хвилину), і при активному особистому кабінеті легко його перевищити.
Webhooks та обробка подій
HelpDeskEddy надсилає webhooks при подіях: створення тікета, нове повідомлення, зміна статусу. Налаштування — в адмінці HelpDeskEddy, розділ «Інтеграції → Webhooks».
На стороні Бітрікс створіть обробник /api/hde-webhook.php, який:
- Перевіряє підпис запиту (HMAC-SHA256 з секретним ключем).
- Парсить JSON-тіло.
- За типом події виконує дію: оновлює UF-поле замовлення, надсилає email-повідомлення менеджеру, створює задачу в CRM.
Що входить в інтеграцію
- Синхронізація користувачів (двостороння) з маппінгом ID
- Передача даних замовлень у тікети (push + pull)
- Віджет зворотного зв'язку з автозаповненням даних клієнта
- Розділ «Мої звернення» в особистому кабінеті
- Webhook-обробник для сповіщень
- Документація з інтеграції та навчання персоналу
- Гарантійна підтримка протягом 30 днів
Терміни та вартість
| Етап | Термін |
|---|---|
| Синхронізація користувачів (двостороння) | 2–3 дні |
| Push даних замовлень + webhook-обробник | 2–3 дні |
| Віджет на сайті + персоналізація | 1 день |
| Розділ «Звернення» в особистому кабінеті | 2–3 дні |
| Тестування та налагодження | 1–2 дні |
| Разом | 1–2 тижні |
Вартість розраховується індивідуально в залежності від складності та доопрацювань. Отримайте консультацію — ми оцінимо ваш проєкт.