Webhook — це спосіб повідомити іншу систему про подію: сервіс, у якому щось змінилося, сам надсилає HTTP-запит на налаштовану адресу одержувача. За періодичної перевірки даних, або polling, одержувач регулярно запитує сервіс, чи з’явилося щось нове. Головна відмінність — хто починає обмін, а не гарантована швидкість чи надійність.
Наприклад, система автоматизації має створити завдання після нового замовлення. Вона може отримати webhook від магазину або сама перевіряти замовлення через API — інтерфейс, за допомогою якого програми обмінюються даними. Обидва підходи можуть виконати це завдання, але потребують різних налаштувань і по-різному поводяться під час збоїв.
Як працюють webhook і polling
У webhook-сценарії одержувач заздалегідь налаштовує адресу для повідомлень і вибирає потрібні події з тих, які підтримує сервіс. Коли така подія стається, сервіс-відправник зазвичай виконує HTTP POST із даними події. Адресу, на якій програма приймає ці запити, називають endpoint, або кінцевою точкою.
У polling-сценарії одержувач запускає перевірки через задані проміжки часу. Програма звертається до API, отримує поточний стан або перелік змін і визначає, чи є нова робота. Для цього їй не потрібна кінцева точка для вхідних webhook-запитів.
Webhook — не окремий універсальний протокол, а спосіб організації інтеграції поверх HTTP. Модель «запит — відповідь» зберігається: відправник робить запит, а одержувач відповідає. Формат даних, перевірку справжності, повторні спроби й порядок доставлення визначає конкретний сервіс.
Webhook і API також не варто вважати взаємозамінними речами. Webhook може лише повідомити про зміну, після чого інтеграція звернеться до API по подробиці. Базові принципи таких звернень пояснює матеріал про REST API простими словами.
Основні відмінності
| Критерій | Webhook | Періодичний polling |
|---|---|---|
| Хто починає обмін | Сервіс-відправник надсилає запит після події | Одержувач запитує дані за розкладом |
| Затримка | Потенційно мала, але миттєве доставлення не гарантоване | Визначається інтервалом перевірок і затримками сервісу |
| Запити без змін | Зазвичай немає запитів саме для перевірки стану | Перевірки відбуваються навіть тоді, коли дані не змінилися |
| Вимоги до одержувача | Доступна відправникові адреса й обробник запитів | Можливість викликати API та запускати перевірки |
| Відновлення після збою | Потрібно перевірити правила повторного доставлення та можливості відновлення пропущених подій | Наступна перевірка може показати актуальний стан; для відновлення проміжних змін потрібна історія в API |
| Отримання кожної події | Можливе для підтримуваних подій, але повнота визначається гарантіями сервісу й обробкою збоїв | Можливе, якщо API надає журнал подій або історію змін, а не лише поточний стан |
Таблиця стосується звичайного періодичного polling. Вона не означає, що будь-який webhook швидший за будь-яке опитування: на результат впливають сервіс, мережа та робота одержувача.
Що означає інтервал перевірки
Умовний розрахунок: якщо перевіряти дані раз на 60 секунд, за годину вийде 60 запитів, навіть якщо змін не було. За рівномірного надходження подій очікування до наступної перевірки становитиме від майже нуля до 60 секунд, у середньому — приблизно 30 секунд.
Це розрахунок для обраного інтервалу, а не вимірювання конкретного сервісу. У реальній системі додаються затримки API, мережі та планувальника, а також обмеження частоти запитів. Практичний висновок: якщо таке очікування прийнятне й запити вкладаються у квоту, polling може бути достатнім без переходу на webhook.
Чому поточний стан — не те саме, що історія подій
Уявімо умовну ситуацію: завдання було відкритим, потім його закрили й знову відкрили. Якщо polling перевірив стан лише до та після цих переходів, обидві відповіді можуть містити «відкрите». Інтеграція не побачить проміжного закриття.
Це не неминучий недолік polling. API може повертати журнал змін, список подій або записи після збереженої позначки. Тоді опитування здатне отримати й проміжні переходи. Вирішальне питання — що саме дозволяє запитати API, а не лише як часто програма до нього звертається.
Webhook може надсилати окреме повідомлення про кожну підтримувану подію, але сама його наявність не гарантує повного доставлення. Потрібні зрозумілі правила повторів, облік прийнятих повідомлень і спосіб відновлення пропущених.
Тому перед вибором визначте результат: потрібен актуальний статус чи повна історія дій? Для синхронізації статусів вимоги можуть бути простішими, ніж для аудиту переходів, нарахувань або запуску незворотних операцій.
Коли ця різниця не має значення
Різниця може не впливати на потрібний результат, якщо вам достатньо актуального стану, а затримка між перевірками прийнятна.
Polling може бути достатнім, коли:
- Дані змінюються рідко й не потребують негайної реакції.
- API дозволяє надійно отримати потрібний стан.
- Запити вкладаються в доступні квоти сервісу.
- Проміжні переходи не запускають окремих важливих дій.
- Регулярні перевірки простіше підтримувати, ніж приймання зовнішніх повідомлень.
За цих умов не варто ускладнювати інтеграцію лише тому, що webhook здається сучаснішим. Приймання запитів, перевірка їхньої справжності та відновлення після збоїв мають давати користь для конкретного завдання.
Це стосується й готових платформ автоматизації. У матеріалі Make, Zapier чи n8n порівнюються самі платформи, а спосіб отримання подій потрібно перевіряти для конкретного підключення.
Що обрати за сценарієм
- Потрібна швидка реакція на нове замовлення або завдання. Розгляньте webhook, якщо сервіс підтримує потрібну подію, а одержувач може безпечно приймати запити. Перевірте вміст повідомлення та потребу в додатковому виклику API.
- Потрібно періодично оновлювати звіт або довідник. Polling доречний, якщо затримка прийнятна й достатньо актуального стану. Інтервал визначайте за потребою в оновленні та квотами API.
- Програма може надсилати запити, але не приймати вхідні підключення. Polling може бути простішим, якщо API надає потрібні дані.
- Пропущене повідомлення може залишити системи в різному стані. Розгляньте webhook для швидкого сповіщення разом із періодичною звіркою через API. Це допоможе лише тоді, коли API дозволяє виявити розбіжності або відновити пропущене.
Комбінований підхід — не вимога стандарту. Якщо API повертає лише поточний стан, звірка допоможе узгодити статуси, але не обов’язково відновить усі проміжні події.
Для побудови автоматизації можна використати готову платформу замість власного обробника. З організацією ланцюжка дій допоможе матеріал про перший сценарій у Make. Водночас платформа не скасовує обмежень сервісу-відправника.
Чому «доставлено» не означає «виконано»
Успішне HTTP-доставлення і завершення бізнес-операції — різні речі. Одержувач може прийняти повідомлення, зберегти його для подальшої роботи й швидко відповісти відправникові. Окремий процес пізніше створить запис або оновить статус. Це називають асинхронною обробкою.
Тому позначка «доставлено» в панелі відправника сама по собі не доводить, що потрібне завдання вже створене.
Показовий приклад — правила GitHub у документації, перевіреній 17 жовтня 2026 року:
- GitHub рекомендує відповісти статусом
2XXпротягом 10 секунд. Якщо відповідь триває довше, сервіс завершує з’єднання й вважає доставлення невдалим. - Невдалі доставлення GitHub не повторює автоматично: потрібне ручне повторне надсилання або власна автоматизація.
- Повідомлення можуть затримуватися на кілька хвилин і надходити не в порядку виникнення подій.
Це правила GitHub, а не універсальні властивості webhook. У рекомендаціях GitHub щодо webhook також описано швидку відповідь і подальшу обробку через чергу.
Для іншого сервісу потрібно окремо перевірити, як він визначає успіх, чи повторює запити, як відновити невдалі доставлення та чи гарантує порядок подій.
Яких помилок уникати
Не вважайте адресу webhook доказом справжності
Обробник має перевіряти справжність повідомлень за механізмом, який передбачає сервіс. Використовуйте HTTPS і, якщо провайдер підтримує підпис із секретом, перевіряйте його. Не передавайте конфіденційні облікові дані в URL: вони можуть потрапити до журналів.
Враховуйте повторні доставлення
Те саме повідомлення може надійти повторно. Обробка має бути ідемпотентною: повторне виконання тієї самої операції не повинно створювати додатковий небажаний результат. Наприклад, повторний запит не має дублювати завдання або нарахування.
Для цього потрібні облік ідентифікаторів і контроль повторної обробки. Конкретний спосіб визначається даними, які надає сервіс, і логікою операції.
Не скорочуйте інтервал polling без перевірки квот
Частіші запити зменшують очікування, але швидше витрачають дозволену кількість звернень до API. Спочатку визначте прийнятну затримку, а потім перевірте, чи вкладається графік у правила сервісу.
Зупиніться перед ризикованою інтеграцією
Якщо webhook запускає платежі, змінює права доступу, видаляє дані або виконує інші незворотні дії, потрібні перевірка справжності повідомлень, безпечне зберігання секретів, журналювання та захист від повторної обробки.
Якщо ви не можете перевірити відправника або пояснити, як відновите пропущені події, залучіть розробника чи адміністратора до ввімкнення таких дій. Помилка тут може призвести до втрати даних або небажаних операцій, а не лише до затримки оновлення.
Чи є long polling тим самим webhook
Ні. За long polling клієнт сам надсилає запит, а сервер утримує його відкритим до появи даних або завершення часу очікування. Після відповіді клієнт зазвичай надсилає наступний запит.
Це відрізняється від коротких перевірок за розкладом, але залишається опитуванням: обмін починає одержувач даних. Механіку описано в RFC 6202 про long polling, опублікованому у квітні 2011 року. Документ пояснює принцип і накладні витрати, але не визначає можливості конкретного сучасного API. Використати long polling можна лише за підтримки сервісу.
Підсумок: починайте з допустимої затримки й вимог до повноти даних. Якщо достатньо періодично отримувати актуальний стан, polling може бути найпростішим рішенням. Якщо потрібна швидка реакція на підтримувану подію, розгляньте webhook із перевіркою справжності, контролем дублікатів і відновленням після збоїв. Коли пропуски критичні, оцінюйте також звірку через API — сама наявність webhook не гарантує повноти даних.
Оновлено 17.10.2026
