TL;DR: Використовуйте API, коли треба запитати щось у зручний вам момент — забрати список замовлень, додати контакт, дізнатись план користувача. Використовуйте webhook, коли треба знати, що щось сталося, у ту саму секунду — оплата пройшла, користувач зареєструвався, угода змінила стадію. API — це pull, webhook — це push, і більшість реальних інтеграцій використовує і те, і те. У цьому матеріалі — компроміси webhook vs api, нюанси безпеки і чотири конкретні приклади (Stripe, Shopify, GitHub, Slack), щоб ви знали, що обрати наступного разу.
Цей гайд — для розробників і техлідів у SMB, які будують інтеграції між SaaS-сервісами: через код або через no-code-платформи на кшталт Make і n8n. Розберемо, де кожен варіант доречний, що ламається в продакшні, і як спроєктувати систему, яка не втрачає дані.
Швидка відповідь: API vs Webhook одним абзацом
API — це дзвінок, який ви натискаєте: ваш код робить запит, інший сервер відповідає даними. Webhook — це дзвінок, який інший сервер натискає на вашу URL-адресу, коли стається подія, яка вас цікавить. API ідеально для передбачуваної on-demand роботи — отримати список товарів, знайти клієнта, оновити запис. Webhook ідеально для реальних реакцій — надіслати алерт у Slack у ту секунду, коли пройшла оплата Stripe, синхронізувати CRM у момент відправлення форми. Майже кожна продакшн-інтеграція поєднує обидва: webhook — для подій, API — для всього іншого.
Що таке API насправді (за 2 хвилини)
Request-response, за вашим графіком
API (Application Programming Interface) — у тому сенсі, який мають на увазі більшість маркетологів і девів, тобто REST API — це набір HTTP-ендпоінтів, які ви викликаєте, щоб читати або писати дані. Ви надсилаєте GET, POST, PUT або DELETE запит; сервер відповідає JSON-ом. Ви контролюєте, коли робиться виклик: щохвилини, щогодини, по натисканню кнопки. Нічого не відбувається, поки ви не запитаєте.
Модель “pull”
Оскільки виклик ініціюєте ви, API — це pull-модель. Щоб бути в курсі змін, доводиться постійно запитувати — патерн називається polling. Polling кожні 5 хвилин означає затримку до 5 хвилин перед тим, як ви побачите нові дані. Polling кожні 10 секунд — це 8 640 марних викликів на день, якщо нічого не змінювалось, і саме так швидко впираються у rate limits.
SDK як зручна обгортка
Більшість серйозних API-провайдерів випускають SDK для популярних мов — Python, Node.js, PHP, Go. SDK ховає від вас деталі: формування JSON-тіла, заголовки авторизації, обробку 429, ретраї з backoff. Прямі HTTP-виклики потрібні лише тоді, коли SDK для вашого стеку немає або він застарів. Для маркетинг-команд, які пишуть інтеграції без SDK, no-code інструменти роблять те саме: ховають HTTP-деталі за UI.
Коли у вас тільки API
Якщо сервіс не пропонує webhook-ів, polling — єдиний варіант. Щоб він був стерпним, використовуйте exponential backoff, зберігайте курсор updated_at, щоб кожен виклик отримував лише нові записи, і поважайте заголовки Retry-After. Якщо ви тільки починаєте працювати з API без коду, у нас є добірка no-code API-інструментів і альтернатив Postman, які добре справляються з цим патерном.
Що таке webhook насправді (за 2 хвилини)
Event-driven, за чужим графіком
Webhook — це URL на вашому сервері, який викликає інший сервіс, коли трапляється подія. Ви реєструєте URL у налаштуваннях провайдера, провайдер його зберігає, і коли спрацьовує подія (нове замовлення, нова реєстрація, повернення оплати), провайдер надсилає HTTP POST на вашу URL із payload події у JSON.
Модель “push”
Webhook інвертує напрямок: виклик до вас ініціює провайдер. Жодного polling, жодної затримки — латентність між подією і повідомленням зазвичай менше 1 секунди. Ціна — потрібен публічно доступний HTTPS-ендпоінт, який завжди працює. Якщо він лежить, провайдер ретраїтить, але лише кілька разів, потім здається.
Політика ретраїв у різних провайдерів
Кожен провайдер має свою політику ретраїв, і її варто знати наперед. Stripe ретраїть до 3 днів із зростаючими інтервалами. Shopify робить 19 спроб протягом 48 годин. GitHub — лише 8 спроб за коротший період. Якщо ваш ендпоінт лежатиме довше за вікно ретраїв провайдера, події втратяться назавжди — і відновити їх можна буде лише через ручний API-запит на стан “за останню добу”.
Чим webhook не є
Webhook — це не окремий протокол, а звичайний HTTP POST із payload-ом, який надсилають вам, а не ви. Хто називає webhook-и “іншою технологією” — ускладнює просту річ. У нас є окремий глибший матеріал про те, що таке webhook і як його протестувати з прикладом хендлера, якщо хочете заглибитись.
Webhook vs API: пліч-о-пліч
Найшвидший спосіб засвоїти різницю — таблиця порівняння. Нижче — сім критеріїв, які насправді важать, коли обираєте один варіант над іншим для реальної інтеграції.
| Критерій | API (pull) | Webhook (push) |
|---|---|---|
| Напрямок | Ви → сервер | Сервер → ви |
| Затримка до нових даних | Залежить від інтервалу polling (1–15 хв) | Менше 1 секунди |
| Серверні ресурси | Марні виклики, коли нічого не змінилось | Нуль викликів, коли нічого не сталось |
| Складність налаштування | API-ключ + scheduled job | Публічний HTTPS-ендпоінт + перевірка підпису |
| Надійність при downtime | Ви ретраїте коли хочете | Провайдер ретраїть 3–10 разів, далі дроп |
| Rate limits | Накладаються провайдером (напр., 100/хв) | Обмежені лише обсягом подій |
| Найкраще для | Bulk-читання, on-demand дії, звіти | Реальні події, low-latency тригери |
Чотири реальні приклади: webhook vs API у продакшні
Stripe: API для дій, webhook для підтвердження
Щоб списати кошти з клієнта, ви викликаєте POST /charges Stripe — дія, яку ініціюєте ви. Щоб дізнатись, чи списання реально пройшло (банк клієнта може відхилити асинхронно), ви чекаєте webhook charge.succeeded. Класична помилка — будувати флоу оплати на відповіді API: вона каже “прийнято”, а не “розраховано”. Реальний settlement приходить через webhook, секунди-хвилини пізніше.
Shopify: webhook для замовлень, API для каталогу
Коли надходить замовлення, Shopify тригерить webhook orders/create протягом 1–3 секунд — ви б ніколи не робили це через API, бо polling замовлень марнотратний і ви б пропустили терміновість. Але щоб масово оновити ціни 500 товарів, REST API — правильний інструмент: передбачуваний, батчевий, не треба чекати подій, які не сталися.
GitHub: webhook для CI/CD, API для решти
CI-системи підписуються на webhook-и GitHub push і pull_request, щоб запускати білди у секунду, коли заливається код. Але якщо вашому боту треба прокоментувати кожен відкритий PR із застарілими лейблами — це робота для API: запросити список PR за запитом, а потім пробігтись по них. Спроба “списку всього” через webhook не має сенсу — webhook-и для нових подій, не для запиту наявного стану.
Slack: webhook для нотифікацій, API для решти
“Incoming webhook” Slack — найпростіший спосіб запостити повідомлення у канал зі свого сервісу: просто POST JSON-у на URL. Але якщо треба шукати користувачів, керувати каналами або будувати інтерактивного бота, потрібен повноцінний API (і Slack-апка). Webhook — для односторонніх нотифікацій; API — для всього двостороннього.
Підводні камені та обмеження (з обох боків)
Webhook-граблі, на які ви наступите першого ж дня
Перевірка підпису. На публічну URL може POST-нути будь-хто. Кожен серйозний провайдер підписує payload (Stripe використовує Stripe-Signature, Shopify — HMAC-SHA256). Перевіряйте підпис ДО обробки — без цього зловмисник може підробити подію “оплата успішна”. Ідемпотентність. Webhook може прийти більше одного разу — особливо коли провайдер думає, що ваш ендпоінт не відповів вчасно, хоча насправді відповів. Якщо “user signed up” приходить двічі, ви не хочете створювати два акаунти — зберігайте event ID у таблиці на 7–14 днів і пропускайте дублікати. Порядок. Webhook-и не гарантовано приходять у порядку. order.created може прийти після order.shipped, особливо коли провайдер ретраїть події з затримкою. Хендлери мають працювати незалежно від порядку — не покладайтесь на “першим прийшов — першим був”.
Логування і retries
Якщо ваш ендпоінт повертає не 2xx, провайдер ретраїтить — зазвичай із exponential backoff протягом годин, іноді днів. Без логів ви не знаєте, що прийшло, що впало і що загубилось. У нас є повний гайд про те, як правильно логувати webhook-и, щоб реально дебажити продакшн.
API-граблі: rate limits і пагінація
У кожного API є rate limits. Уперлись — і отримаєте 429 на хвилини. Виклик “list all customers” майже завжди повертає посторінкові результати: забули піти за заголовком Link або токеном next_cursor — обробили лише першу сторінку. Ще: API eventually consistent. Запис, який ви щойно створили через API, може не зʼявитись у list-виклику кілька секунд — це щоразу когось дивує.
Безпека: захищайте обидва ендпоінти
Ваш webhook URL — публічний, і боти його сканують. Ротуйте URL-и, які зливаються, перевіряйте підписи і вішайте rate limiting на сам ендпоінт. Ми писали про WAF, rate limiting і CAPTCHA в окремому матеріалі — більшість порад стосується webhook-ендпоінтів, не лише сторінок логіну.
Decision framework: коли що обирати
Обирайте webhook, якщо дані мають форму події (“сталося X”), важлива затримка менше хвилини, і провайдер його пропонує. Приклади: оплати, замовлення, відправки форм, зміни статусів, рух стадій угоди. Класичний поділ між клієнтським і серверним трекінгом — див. наш матеріал про Facebook Pixel vs Meta CAPI — це по суті та сама історія push vs pull.
Обирайте API, якщо треба читати наявний стан, робити bulk-операції, точно контролювати тайминг, або провайдер не пропонує webhook-ів. Приклади: тижневі KPI-звіти, end-of-day реконсиляція, bulk-імпорти, on-demand пошук.
Використовуйте обидва, коли потрібні real-time тригери і початкове підкачування даних. Поширений патерн: webhook спрацьовує, коли надходить нове замовлення, ваш хендлер викликає API, щоб витягти повні деталі замовлення (товари, адресу доставки), які не вмістились у payload webhook-а. No-code платформи роблять це без коду — див. наше порівняння n8n vs Make у 2026, обидві нативно тримають і webhook-тригери, і API-дії.
Висновок
API — це те, що викликаєте ви. Webhook — це те, що викликає вас. API виграє, коли треба on-demand читання й запис; webhook виграє, коли треба реагувати на події в момент, коли вони стаються. Більшості продакшн-інтеграцій потрібні обидва — і питання дизайну не “що з двох”, а “що для якої задачі”. Випишіть кожну подію, яка цікавить вашу інтеграцію. Все, що real-time тригер, — webhook. Решта — API. Додайте перевірку підпису, ідемпотентність, логування — і у вас система, яка не втратить даних першої ж невдалої ночі провайдера.
FAQ
Webhook — це різновид API?
Формально так — це HTTP-інтерфейс, як і будь-який REST API. Практична різниця у напрямку: “звичайний” API очікує, що ви його викличете, webhook — це API-ендпоінт, який реалізуєте ви, а викликає провайдер. Дехто з цієї причини називає їх “reverse APIs”.
Webhook-и швидші за API?
Webhook-и доставляють події з набагато меншою затримкою, ніж polling — зазвичай менше 1 секунди проти хвилин для типового polling. Але сам HTTP-виклик — однакової швидкості. “Швидше” тут означає “ви знаєте раніше”, а не “запит швидше”.
Чи може webhook повністю замінити API?
Ні. Webhook-и спрацьовують лише на події, які провайдер вирішив публікувати. Щоб прочитати наявні дані, отримати список записів або виконати дію, вам усе одно потрібен API. На практиці webhook-ами вас сповіщають, а API ви робите роботу.
Як протестувати webhook локально?
Використовуйте тунель типу ngrok, Cloudflare Tunnel або Tailscale Funnel, щоб виставити локальний сервер на публічну URL, потім вкажіть цю URL у налаштуваннях webhook-а провайдера. Більшість провайдерів також мають кнопку “send test event” у дашборді, щоб ганяти payload без реальної дії.
Чим відрізняються webhook та “incoming webhook”?
“Webhook” зазвичай означає, що провайдер надсилає події на вашу URL. “Incoming webhook” (термін популяризував Slack) — навпаки: ви POST-ите повідомлення на URL провайдера, щоб запхати контент у їхню систему. Той самий протокол, протилежний напрямок — нейминг навмисно заплутаний.
Чи потрібно перевіряти підпис webhook-а, якщо ендпоінт на HTTPS?
Так. HTTPS захищає дані в дорозі від підслуховування, але не доводить, що відправник — той, за кого себе видає; на HTTPS-URL може POST-нути будь-хто з вашою адресою. Перевірка підпису (HMAC зі спільним секретом) — це те, що доводить, що payload справді від реального провайдера.