Що таке webhook: просте пояснення без коду
Webhook простими словами: чим відрізняється від API, як він працює в no-code інструментах на практиці, і коли він реально потрібен.
Коротка відповідь
Webhook — це адреса (URL), на яку один сервіс автоматично надсилає повідомлення іншому сервісу в момент, коли в ньому щось трапляється. Найпростіша аналогія: не ви щохвилини телефонуєте комусь і питаєте "у тебе вже є новини?" (це API-запит), а вам самим телефонують, щойно новина з'явилась (це webhook). У no-code інструментах (n8n, Zapier, Make) webhook — це майже завжди перший крок воркфлоу: подія в зовнішньому сервісі миттєво запускає весь ланцюжок автоматизації.
Як це працює покроково
- У сервісі А (наприклад, Google Forms, Telegram, платіжна система) відбувається подія — хтось заповнив форму, написав боту, оплатив рахунок
- Сервіс А формує пакет даних про цю подію (зазвичай у форматі JSON) і надсилає його на заздалегідь вказану адресу — URL вебхука
- Ця адреса належить сервісу Б (вашому no-code інструменту чи власному серверу) і постійно "слухає" вхідні запити
- Сервіс Б отримує дані й одразу запускає свою логіку — записує рядок у таблицю, шле сповіщення, створює задачу в CRM
Уся ця послідовність займає секунди, без жодного ручного втручання — і саме тому webhook лежить в основі більшості "реального часу" автоматизацій.
Чим webhook відрізняється від звичайного API-запиту
Це ключова різниця, яку часто плутають:
| API-запит (звичайний) | Webhook | |
|---|---|---|
| Хто ініціює обмін | Ви самі надсилаєте запит і чекаєте відповідь | Зовнішній сервіс сам надсилає дані, коли трапляється подія |
| Коли отримуєте дані | Тільки коли самі попросили (опитування/polling) | Миттєво, у момент події (push) |
| Типовий приклад | "Перевіряти щохвилини, чи є нові листи" | "Повідомити мене, щойно прийде новий лист" |
| Навантаження | Багато зайвих запитів "про всяк випадок" | Один запит рівно тоді, коли є що передати |
Простими словами: API — це коли ви питаєте, webhook — коли вам самі повідомляють.
Практичний приклад у no-code
Уявіть інтернет-магазин, який хоче миттєво отримувати сповіщення в Telegram про кожне нове замовлення:
- Платіжний сервіс (наприклад, Stripe чи LiqPay) підтримує вебхуки на подію "оплата успішна"
- У налаштуваннях платіжного сервісу вказується URL вебхука, згенерований в n8n чи Make
- Щойно клієнт оплачує замовлення, платіжний сервіс автоматично відправляє дані на цю адресу
- Воркфлоу в no-code інструменті отримує дані замовлення й одразу шле повідомлення в Telegram-канал
Без вебхука довелось би або перевіряти статус замовлень вручну, або будувати систему, яка щохвилини опитує платіжний сервіс "чи є нові оплати" — набагато повільніше й марнотратніше по ресурсах.
Коли вебхук — не найкращий вибір
Вебхуки чудові для подій "щось трапилось" (нове замовлення, новий лист, нове повідомлення), але не підходять, якщо:
- Потрібні дані, яких немає в події. Вебхук передає лише той пакет даних, який сервіс-відправник вирішив включити — якщо потрібна додаткова інформація (наприклад, повна історія клієнта), доведеться робити додатковий API-запит услід за вебхуком
- Сервіс-джерело взагалі не підтримує вебхуки. Не всі сервіси, особливо старі чи внутрішні корпоративні системи, вміють їх надсилати — тоді єдиний варіант це периодичний polling через звичайний API-запит за розкладом
- Потрібна гарантія доставки при недоступності отримувача. Якщо ваш сервер чи no-code воркфлоу тимчасово недоступний у момент відправки, поведінка залежить від сервіса-джерела — деякі повторюють спроби (retry) кілька разів, інші втрачають подію назавжди
Часті помилки новачків
Плутанина "webhook" і "API" як синонімів. Вебхук технічно теж є HTTP-запитом (як і API-виклик), але напрям і ініціатор протилежні — це не одне й те саме, хоч обидва працюють через HTTP.
Забути, що вебхук потребує постійно доступної публічної адреси. Локальний комп'ютер чи сервер за домашнім роутером без публічної IP-адреси не може приймати вебхуки напряму — саме тому хмарні no-code платформи (n8n Cloud, Zapier, Make) або тунелювання (ngrok і подібні для локальної розробки) такі популярні саме для цього сценарію.
Не перевіряти, чи справді вебхук зареєстрований і "слухає". Найчастіша практична проблема — воркфлоу виглядає готовим, але сама адреса вебхука неактивна в потрібний момент (наприклад, у n8n — воркфлоу не активовано). Детальний розбір типових причин і фіксів — у статті чому n8n webhook не спрацьовує.
Часті питання
Чи потрібно знати програмування, щоб користуватись вебхуками?
Ні, у сучасних no-code інструментах вебхук — це просто нода/блок у воркфлоу, яка автоматично генерує готову URL-адресу. Вся технічна складність (формат HTTP-запиту, парсинг JSON) прихована від користувача — потрібно лише вказати цю адресу в налаштуваннях сервіса-джерела.
Чим вебхук відрізняється від звичайного тригера за розкладом (schedule trigger)?
Тригер за розкладом запускає воркфлоу через фіксовані проміжки часу (наприклад, щогодини), незалежно від того, чи є що обробляти. Вебхук запускає воркфлоу рівно в момент реальної події — швидше й без зайвих "порожніх" запусків, але вимагає, щоб сервіс-джерело вмів надсилати вебхуки.
Чи безпечно приймати вебхуки від зовнішніх сервісів?
Сама по собі URL-адреса вебхука — це, по суті, публічний вхід у ваш воркфлоу, тому серйозні сервіси додають підпис (signature) до кожного запиту, яким можна перевірити, що дані справді прийшли від легітимного джерела, а не від зловмисника, який вгадав адресу. Перевіряти цей підпис варто в будь-якому вебхуку, що запускає дії з реальними наслідками (списання коштів, зміна даних).
Приклад використання вебхука на практиці, з якого варто почати?
Гарний перший проєкт — підключення Telegram-бота до Google Таблиць через n8n, де Telegram Trigger по суті і є вебхуком: покрокова інструкція є в статті як підключити Telegram-бота до Google Sheets через n8n.
Дата останньої перевірки актуальності: 18 серпня 2026 р.