Підтримка рідко живе в ізоляції. Коли створюється тикет, ви можете захотіти повідомити команду в чат, оновити CRM, порахувати метрику чи запустити внутрішній процес. Робити це вручну — марнування часу й джерело помилок: хтось забуде перевірити нову скриньку, хтось скопіює дані з опискою, хтось згадає про тикет лише за два дні.
Саме тут у гру вступають вебхуки: механізм, який дозволяє вашій системі дізнаватися про події підтримки автоматично, у момент, коли вони стаються. У цій статті — що таке вебхук, які події варто слухати, як виглядає типовий payload, як написати простий обробник і як зробити його надійним, навіть якщо ви ще ніколи не писали інтеграцій.
Що таке вебхук простими словами
Вебхук — це «дзвінок навпаки». Замість того щоб ваша система постійно питала «а що там нового?» (це називається polling), система підтримки сама надсилає HTTP-запит на вказаний вами URL щоразу, коли стається подія.
Уявіть різницю між дзвінком у двері й постійним визиранням у вічко: перше — це вебхук, друге — опитування. Ви один раз даєте адресу свого обробника — і далі просто отримуєте сповіщення, коли щось справді сталося. Це і швидше, і надійніше, і значно дешевше за постійні запити «чи є щось нове» раз на кілька секунд.
Технічно вебхук — це звичайний POST-запит на ваш ендпоінт. Не потрібні спеціальні бібліотеки чи протоколи: достатньо сервера, що вміє приймати HTTP-запити і повертати статус-код. Такий підхід підходить будь-якій команді — від одного розробника з невеликим скриптом до великого бекенду з чергами й мікросервісами, бо складність обробника завжди можна нарощувати поступово.
Які події варто слухати
Не кожна подія підтримки заслуговує на окрему автоматизацію, але деякі варто слухати майже завжди:
- Створено тикет — щоб одразу сповістити команду в робочому чаті або завести запис у CRM. Це найчастіший тригер: перше звернення нового клієнта часто важливіше за все інше.
- Нове повідомлення — щоб реагувати на відповідь клієнта в реальному часі, наприклад підняти пріоритет, якщо клієнт написав повторно без відповіді оператора.
- Змінено статус — щоб рахувати метрики (скільки тикетів закрито за день), закривати повʼязані внутрішні задачі або знімати позначку «потребує уваги».
- Призначено оператора — щоб синхронізувати навантаження з внутрішнім таск-трекером або нагадати оператору в особистому чаті.
- Додано тег — щоб маршрутизувати тикет далі: наприклад, тег «білінг» може автоматично сповіщати окрему команду.
Вибирайте події виходячи з того, яке рішення ви приймете у відповідь. Якщо на подію немає дії — можливо, її й не варто слухати. Підписатися одразу на всі типи подій спокусливо, але на практиці це лише збільшує навантаження на ваш обробник і кількість коду, який ніколи не виконує корисної роботи.
Як виглядає payload
Зазвичай вебхук приходить як POST-запит із JSON-тілом: тип події, ідентифікатор тикета, джерело (Telegram, віджет, API) і корисні дані — текст повідомлення, статус, теги. Ось ілюстративний приклад того, як може виглядати таке тіло для події зміни статусу:
{
"event": "ticket.status_changed",
"ticket_id": "8f21a4",
"source": "widget",
"occurred_at": "2026-03-01T10:15:00Z",
"data": {
"previous_status": "open",
"new_status": "resolved"
}
}Це саме приклад структури, а не гарантована специфікація конкретного постачальника — назви полів можуть відрізнятися. Головне, що ви завжди отримуєте достатньо контексту, щоб зрозуміти, що сталося, з яким тикетом і звідки він прийшов, без додаткового запиту до API.
Ваш обробник читає це тіло й вирішує, що робити. Найважливіше правило на боці обробника — швидко відповісти кодом 200. Якщо ваша логіка складна (звернення до кількох сервісів, повільні запити до бази), важку роботу краще винести в чергу, а не тримати відправника вебхука на лінії в очікуванні відповіді.
Приклад простого обробника
Обробник вебхука не мусить бути складним. У найпростішому вигляді це два кроки: прийняти й підтвердити подію, а потім — окремо — обробити її.
function handleWebhook(request):
event = parseJson(request.body)
if not isValidSignature(request):
return 401
enqueue(event)
return 200
function processQueue():
for event in queue:
if event.type == "ticket.created":
notifyTeamChat(event)
else if event.type == "ticket.status_changed":
updateCrmRecord(event)
else if event.type == "message.new":
maybeEscalate(event)Розділення на «прийняти» і «обробити» — не примха, а страховка. Якщо ваш notifyTeamChat чи updateCrmRecord впаде або сповільниться, це не вплине на швидкість відповіді на сам вебхук, і відправник не почне повторювати запит через таймаут.
Поради щодо надійності
Кілька простих правил рятують від більшості проблем із вебхуками на практиці:
- Робіть обробник ідемпотентним. Той самий вебхук може прийти двічі — через збій мережі чи повторну спробу відправника. Повторна обробка не повинна ламати дані: перевіряйте, чи вже застосована ця подія, за її ідентифікатором.
- Перевіряйте підпис, якщо він є, щоб приймати лише справжні події, а не підробки від зловмисника, який вгадав ваш URL.
- Не блокуйте відповідь. Прийняли, поставили в чергу, відповіли 200 — а вже потім робите основну роботу. Довга відповідь часто інтерпретується як помилка й провокує зайві повтори.
- Логуйте кожну подію, щоб мати змогу відтворити, що і коли прийшло, якщо щось пішло не так через тиждень.
- Майте план на збій. Якщо ваш обробник впав і не відповів, добра система підтримки повторить спробу пізніше — але ваш код має бути готовий обробити «запізнілу» подію коректно.
Жодна з цих порад не вимагає складної інфраструктури — навіть невелика черга в памʼяті чи проста таблиця «оброблені події» вирішує 90% типових проблем. Якщо ви лише починаєте, не обовʼязково будувати ідеальну систему одразу: почніть з логування і простої перевірки за ідентифікатором події, а чергу й підпис додасте, коли інтеграція справді почне жити в проді.
Типові сценарії використання
На практиці вебхуки найчастіше застосовують для кількох повторюваних задач:
- Сповіщення команди. Новий тикет одразу зʼявляється в робочому чаті — ніхто не пропустить перше звернення клієнта.
- Синхронізація з внутрішніми інструментами. Статус тикета оновлює запис у вашій системі обліку клієнтів без ручного копіювання.
- Автоматичні дії за тегом. Тег «терміново» може створювати задачу у внутрішньому трекері або сповіщати відповідального напряму.
- Аналітика в реальному часі. Замість щоденного експорту даних ви накопичуєте події одразу, коли вони стаються.
Це той самий принцип, що лежить в основі ширшої ідеї — автоматизувати підтримку, не втрачаючи довіри клієнтів: автоматизація працює найкраще, коли вона реагує на реальні події, а не підмінює живу відповідь оператора.
Почніть з однієї-двох подій, які реально розвʼязують проблему вашої команди — наприклад, сповіщення про новий тикет, — а решту додавайте поступово, коли побачите, що черговий ручний процес знову й знову зʼїдає час.
Вебхуки й API — дві сторони інтеграції
Вебхуки відповідають на питання «як дізнатися, що щось сталося», а API — «як самому щось зробити»: створити тикет, дописати повідомлення, змінити статус. Разом вони дають повний контроль над інтеграцією підтримки у ваші процеси: вебхук повідомляє про подію, а у відповідь ви через API вносите зміни або запитуєте додаткові деталі.
Якщо вебхуки — це вхідний потік подій, то API — вихідний потік дій. Більшість повноцінних інтеграцій використовують обидва напрямки одночасно. Про другу сторону — стаття про API підтримки.
Як це реалізовано в Duck Float
У Duck Float є вебхуки та журнал подій: ваша система дізнається про кожну зміну тикета — від створення до нового повідомлення й зміни статусу до призначення оператора чи додавання тега — і може реагувати автоматично. Разом із публічним API це дозволяє вбудувати підтримку в будь-який ваш процес, без ручного перенесення даних між системами.
А всередині кожне звернення — незалежно від того, прийшло воно з Telegram-бота, чат-віджета на сайті чи через API, — однаково стає тикетом з історією, статусом і тегами. AI готує чернетку відповіді мовою клієнта, оператор лише підтверджує її клавішею Tab або редагує — нічого не йде клієнту без перегляду людиною. На час бети Duck Float безкоштовний. Хочете підключити вебхуки до своїх процесів або просто подивитися, як це працює, — напишіть нам через віджет на цьому сайті.