Deskhero
Українська
Спробувати безкоштовно

← Back to articles

Що роблять вебхуки хелпдеску і чому вони важливі

Що роблять вебхуки хелпдеску і чому вони важливі

Вебхук helpdesk — це вихідний HTTP-запит, який надсилає події щодо заявок до іншої системи одразу після їх виникнення. Він може запускати сповіщення, автоматизації або синхронізацію даних без частого опитування. Надійна інтеграція все одно потребує ретельного налаштування: перевіряйте кожен запит, швидко підтверджуйте отримання та тестуйте кінцеву точку, перш ніж довірити їй робочий трафік.

Коротко:

  • Вебхуки можуть доставляти оновлення заявок із меншою затримкою та з меншою кількістю API-викликів, ніж часте опитування.
  • Налаштування зазвичай передбачає публічну кінцеву точку HTTPS, підписку на події, перевірку запитів і тестування на репрезентативних подіях.
  • Засоби безпеки залежать від постачальника, але зазвичай охоплюють HTTPS, перевірку підпису або токена, ротацію секретів і обробку з мінімально необхідними привілеями.
  • Отримувачі мають бути готовими до дублікатів або подій, що надходять не в порядку їх виникнення, використовуючи ідемпотентну обробку та звірку з поточним станом.
  • Deskhero наразі не надсилає вихідні вебхуки. Його REST API можна опитувати, коли кастомній інтеграції потрібні дані заявок.

Зміст

Як працюють вебхуки helpdesk: подія, POST, корисне навантаження

Вебхук helpdesk починається з події. Хтось відкриває заявку, Користувач змінює її статус, клієнт відповідає або змінюється пріоритет. Якщо платформа пропонує вебхук для цієї події і ви підписалися на нього, платформа надсилає HTTP-запит на зареєстровану вами URL-адресу. На відміну від опитування за фіксованим розкладом, отримувачу не потрібно постійно запитувати, чи щось змінилося. Корисні навантаження вебхуків часто мають формат JSON, хоча точний формат і набір полів залежать від постачальника.

Схема полів корисного навантаження JSON вебхука

Корисне навантаження події створення заявки може містити ідентифікатор заявки, статус, пріоритет, дані ініціатора запиту та інформацію про те, що спричинило подію. Не припускайте, що ці поля існують або завжди мають однакову структуру. Вважайте актуальну схему подій постачальника першоджерелом і перевіряйте корисні навантаження перед їх використанням.

Практична відмінність від опитування полягає в часі та контролі. Вебхук може повідомити ваш отримувач невдовзі після події, тоді як опитувач виявляє зміни під час наступного запуску. Опитування часто простіше, якщо оновлення не є терміновими. Вебхуки корисні, коли важлива мала затримка, а постачальник підтримує потрібні вам події та засоби безпеки.

Які найкращі варіанти використання вебхуків helpdesk?

Вебхуки найцінніші, коли іншій системі потрібно оперативно реагувати на подію, пов’язану із заявкою. Поширені приклади:

  • Сповіщення в каналах. Нова або термінова заявка може запускати сповіщення в інструменті для спільної роботи, якщо helpdesk генерує таку подію, а інтеграція-отримувач її підтримує.
  • Оновлення CRM. Вибрану активність щодо заявки можна скопіювати до запису клієнта, щоб команда підтримки та відділ продажів мали відповідний контекст.
  • Тригери ескалації. Термінова подія може створити інцидент або сповіщення в системі для чергової команди.
  • Завантаження аналітичних даних. Події заявок можна передавати до черги або конвеєра даних для подальшої звітності.
  • Координація між системами. Подія заявки може створити або оновити пов’язаний робочий елемент для іншої команди.

Для таких процесів також потрібні чітко визначений відповідальний і обробка помилок. Вебхук — це лише механізм доставки. Система-отримувач відповідає за перевірку події, застосування бізнес-правил і відновлення роботи, коли наступні сервіси недоступні.

Як налаштувати вебхук helpdesk?

Точний процес залежить від платформи, але типове налаштування складається з таких кроків:

  1. Ознайомтеся з документацією постачальника. Підтвердьте доступні типи подій, схему корисного навантаження, метод автентифікації, тайм-аут, політику повторних спроб і функції журналу доставки.
  2. Відкрийте публічну кінцеву точку HTTPS. Створіть маршрут, який приймає формат запитів постачальника. Багато систем вебхуків використовують POST-запити з JSON, але ваша реалізація має відповідати задокументованому контракту.
  3. Зареєструйте кінцеву точку та події. Додайте URL-адресу через адміністративний інтерфейс або API платформи, а потім підпишіться лише на ті події, які потрібні вашій інтеграції.
  4. Налаштуйте перевірку запитів. Якщо постачальник надає секрет для підпису або токен перевірки, зберігайте його в менеджері секретів або захищеній змінній середовища. Ніколи не зашивайте його безпосередньо у систему контролю версій.
  5. Швидко підтверджуйте отримання. Повертайте очікувану успішну відповідь до початку повільної роботи з наступними сервісами. Документація вебхуків Stripe рекомендує відкладати складну обробку до моменту, коли кінцева точка поверне успішну відповідь.
  6. Протестуйте до запуску. Використовуйте тестові події постачальника або середовище розробки. Захищений інструмент переспрямування може допомогти під час локальної розробки, але не відкривайте незахищений сервіс розробки для робочого трафіку.
  7. Перевіряйте результати доставки. Якщо постачальник надає журнал доставки, використовуйте його, щоб порівнювати надіслані події з відповідями вашого отримувача та записами обробки.

Швидке підтвердження зменшує ймовірність того, що постачальник сприйме повільного отримувача як невдалу доставку. Постановка перевіреної події в чергу до подальшої обробки також спрощує повторну спробу виконати власну роботу без необхідності просити відправника надіслати подію повторно.

Як захистити кінцеву точку вебхука helpdesk?

URL-адреса вебхука доступна ззовні вашої мережі, тому отримувач не має довіряти запиту лише тому, що він надійшов на правильний шлях.

Використовуйте HTTPS із дійсним сертифікатом і актуальною конфігурацією TLS, що підтримується. Потім реалізуйте задокументований механізм перевірки постачальника. Це може бути підпис HMAC, токен перевірки, асиметричні підписи або інша схема. Для перевірки підпису часто потрібне точне необроблене тіло запиту, тому виконуйте перевірку до його аналізу або перетворення.

Захищайтеся від повторного відтворення запитів, якщо схема постачальника підтримує часові мітки або унікальні ідентифікатори подій. Порівнюйте підписи за сталий час, відхиляйте недійсні запити та не додавайте секрети або персональні дані до журналів застосунку. За можливості змінюйте секрети й документуйте процедуру переходу, якщо під час ротації одночасно мають працювати старий і новий секрети.

Надайте процесору вебхуків лише необхідні дозволи. Якщо постачальник публікує стабільні діапазони IP-адрес джерел, список дозволених адрес може бути додатковим засобом контролю, але не має замінювати перевірку запитів. Обережно застосовуйте обмеження частоти, відстежуйте помилки та зберігайте лише ті дані події, які потрібні для процесу.

Як захистити кінцеву точку вебхука helpdesk? Оглядова схема

Як тестувати й налагоджувати вебхуки helpdesk?

Почніть із розділення проблем доставки та проблем обробки. Перевірте, чи надіслав постачальник подію, чи дійшов запит до вашої кінцевої точки, яку відповідь повернула кінцева точка та чи завершила прийнята подія подальшу роботу.

  • Використовуйте надані постачальником тестові події, якщо вони доступні, а потім тестуйте репрезентативні реальні події в непрацюючому середовищі.
  • Записуйте ідентифікатор події, тип події, час отримання, результат перевірки, статус відповіді та результат обробки. Редагуйте секрети й мінімізуйте обсяг збережених персональних даних.
  • Використовуйте журнал доставки платформи для перевірки кодів відповідей і повторних спроб. Zendesk документує активність вебхуків і деталі викликів для налагодження свого сервісу вебхуків.
  • Порівнюйте запис доставки постачальника з журналами зворотного проксі та застосунку. Відсутні заголовки або зміни тіла можуть вказувати на проблеми в конфігурації проміжного програмного забезпечення чи проксі.
  • Тестуйте тайм-аути, недійсні підписи, дублікати ідентифікаторів подій, недоступні наступні сервіси та події, доставлені в неочікуваному порядку.

Порада професіонала: Зберігайте достатньо структурованої історії доставки, щоб відстежувати помилки, але встановіть період зберігання та не записуйте необроблені корисні навантаження, якщо вони справді не потрібні й належним чином не захищені.

Як обробляти дублікати або події вебхуків, що надходять не в порядку?

Не припускайте, що кожна подія буде доставлена рівно один раз або що події завжди надходитимуть у порядку створення. Поведінка доставки залежить від постачальника, а повторні спроби можуть створювати дублікати. Огляд Hookdeck порівнює підходи з доставкою щонайменше один раз і рівно один раз.

Зробіть обробники ідемпотентними. Якщо постачальник надає стабільний ідентифікатор події, записуйте його та не застосовуйте ту саму операцію двічі. Для змін стану використовуйте часові мітки подій або значення послідовності, якщо постачальник їх визначає, і отримуйте поточний стан ресурсу, коли правильність важливіша за обробку кожного проміжного переходу. Ставте невдалу роботу в чергу з обмеженою кількістю повторних спроб і поступовим збільшенням інтервалу, а постійні помилки надсилайте до черги невдалих повідомлень, доступної для перевірки, або еквівалентного процесу.

Варіант API від Deskhero

Deskhero наразі надає REST API з персональними токенами носія, але не надсилає вихідні вебхуки. Інтеграція, якій потрібні дані заявок Deskhero, має опитувати API з відповідним інтервалом і дотримуватися його обмеження частоти. Це інша модель, ніж описана вище доставка подій, тому передбачте контрольні точки, посторінкове завантаження, усунення дублікатів і відновлення після збою завдання опитування.

Вибір між вебхуками та опитуванням

Вибирайте підхід на основі системи, з якою ви інтегруєтеся, а не припускаючи, що кожен helpdesk підтримує обидві моделі. Вебхуки можуть зменшити затримку виявлення змін, але потребують публічного отримувача та ретельної обробки доставки. Опитування потребує планування й логіки контрольних точок, але може бути простішим в експлуатації та синхронізації.

Deskhero

Deskhero перетворює поштову скриньку Gmail або Microsoft 365 на спільний helpdesk, зберігаючи наявну адресу електронної пошти компанії. Він пропонує двосторонню синхронізацію електронної пошти, вбудовані автоматизації заявок, чернетки відповідей зі штучним інтелектом на основі знань робочого простору та REST API для кастомних інтеграцій. Автоматизації Deskhero запускаються під час створення нових заявок; вони не є заміною вихідним вебхукам. Користувачі Shopify також можуть підключити інтеграцію Shopify, щоб переглядати відповідну інформацію про замовлення та клієнта в Deskhero. 30-денна безкоштовна пробна версія доступна без банківської картки.

Де дізнатися більше про стандарти вебхуків

Єдиного стандарту вебхуків, який змусив би всіх постачальників працювати однаково, не існує. Використовуйте документацію свого постачальника як джерело інформації щодо схем подій, перевірки, повторних спроб і тайм-аутів. Документація вебхуків Notion містить конкретний приклад перевірки підписки та доставки подій.

Джерела

FAQ

Що саме таке вебхуки?

Вебхук — це HTTP-запит, який одна система надсилає на зареєстровану URL-адресу після визначеної події. Він містить інформацію, яка дає змогу системі-отримувачу вирішити, як реагувати.

Які недоліки використання вебхуків?

Вебхуки потребують захищеного отримувача, доступного з публічної мережі. Інтеграція також має враховувати специфічні для постачальника перевірку, повторні спроби, дублікати подій, можливе змінення порядку, простої, моніторинг і зміни схем подій.

Що таке вебхук у порівнянні з API?

API зазвичай дає змогу вашому програмному забезпеченню запитувати дані або запускати дію. Вебхук дає змогу іншій системі надсилати подію вашому отримувачу. Багато інтеграцій використовують обидва підходи: вебхук повідомляє про зміну, а API надає поточні дані ресурсу.

Чи можете ви навести приклад вебхука helpdesk?

Helpdesk, який підтримує вихідні вебхуки, може надсилати подію створення заявки вашому отримувачу. Після перевірки запиту ваша інтеграція може додати сповіщення до командного каналу або оновити запис у CRM. Deskhero наразі не надсилає вихідні вебхуки, тому кастомні інтеграції Deskhero мають натомість опитувати його REST API.