Входящий вебхук

Как работает Входящий вебхук

Входящий вебхук функционирует как приёмник данных, который постоянно ожидает входящих соединений. Когда в стороннем приложении происходит триггерное Событие (например, Создание заказа), система формирует HTTP-запрос с полезной нагрузкой и отправляет его на заранее настроенный URL. Ваш Сервер принимает пакет, проверяет его целостность и безопасность, а затем передаёт данные в базу или другую систему. Если обработка завершается успешно, возвращается код ответа HTTP 200 OK. При ошибке или таймауте внешний Сервис применяет экспоненциальную задержку и пытается отправить Уведомление повторно до пяти раз.

Зачем нужен Входящий вебхук

Входящий вебхук необходим для устранения задержек, возникающих при традиционном опросе API. Вместо того чтобы ваш Сервер каждые несколько минут спрашивал «есть ли новые данные?», внешняя система сама сообщает о событии в момент его возникновения. Это экономит вычислительные ресурсы и пропускную способность канала. Для интернет-маркетолога такой подход означает мгновенную обработку заявок из рекламных кабинетов, что повышает конверсию. Технически механизм упрощает архитектуру приложений, позволяя связывать разрозненные сервисы через простые HTTP-соединения без сложных протоколов обмена.

Классификация зависит от формата данных, уровня защиты и назначения. По формату payload различают JSON (наиболее распространён), XML и form-urlencoded. По уровню безопасности выделяют публичные эндпоинты без защиты (не рекомендуется для продакшена), endpoints с базовой авторизацией по токену и защищённые варианты с проверкой HMAC-подписи. По назначению механизмы делятся на информационные (уведомления о статусах), Транзакционные (обработка платежей) и управляющие (команды для ботов). Выбор вида зависит от чувствительности передаваемых данных и требований надёжности интеграции.

Где используется Входящий вебхук

Входящий вебхук широко применяется в e-commerce для уведомления магазинов об успешных оплатах через Stripe или PayPal. В маркетинге он интегрируется с Google Ads и Яндекс.Директ для передачи данных о конверсиях напрямую в CRM. Системы мониторинга используют endpoint для отправки алертов в Slack или Telegram при падении серверов. Разработчики применяют механизм для автоматического деплоя кода при пуше в Git-Репозиторий. Любая задача, требующая немедленной реакции на изменение состояния внешней системы, решает этот инструмент.

Для демонстрации работы механизма приведён пример простого обработчика на Node.js. Код демонстрирует парсинг тела запроса и проверку сигнатуры. Важно использовать HTTPS, чтобы защитить передаваемые данные от перехвата. Сервер должен быстро ответить клиенту, даже если тяжёлая логика обработки будет выполнена асинхронно в фоне.

const express = require('express');
const crypto = require('crypto');
const app = express();

// Парсим JSON тело запроса
app.use(express.json());

// Секретный ключ для проверки подлинности
const WEBHOOK_SECRET = 'my_super_secret_key';

app.post('/webhook', (req, res) => {
  // Вычисляем ожидаемую подпись
  const signature = req.headers['x-signature'];
  const hmac = crypto.createHmac('sha256', WEBHOOK_SECRET);
  const digest = hmac.update(JSON.stringify(req.body)).digest('hex');

  // Проверяем подлинность запроса
  if (signature !== digest) {
    return res.status(403).send('Invalid signature');
  }

  // Обработка события
  console.log('Received event:', req.body.event_type);
  
  // Возвращаем успешный ответ
  res.status(200).json({ received: true });
});

app.listen(3000, () => console.log('Server running on port 3000'));