# Подписанный webhook с защитой от дублей

**Задача:** проверить подпись и структуру, атомарно принять событие в журнал и определить маршрут.  
**Сложность:** высокая.  
**Схема:** Webhook → HMAC SHA-256 исходного тела → проверка → проверка структуры → PostgreSQL с уникальным ключом → HTTP-ответ.  
**Узлы:** Webhook, Crypto, Code, IF, PostgreSQL, Respond to Webhook.  
**Зависимости:** n8n 2.42.6 с узлом Crypto v2, PostgreSQL.  
**Файлы:** `webhook.json`, `webhook.sql`.

## Установка
1. Создайте отдельную тестовую базу и выполните `webhook.sql`.
2. Импортируйте JSON. Измените путь webhook `manin-inbox-change-me` и подключите credential Crypto с собственным HMAC Secret. Подключите собственный credential PostgreSQL.
3. Отправитель должен подписывать точные байты тела JSON с помощью HMAC-SHA256 и отправлять заголовок `X-Signature-256: sha256=<64 hex>`. Адаптируйте заголовок и алгоритм к документации конкретного поставщика; без корректной подписи обработка отклоняется.
4. Используйте HTTPS и ограничение частоты запросов на reverse proxy. Запустите пробные запросы до публикации webhook.

## Тестовые данные и результат
Тело: `{"id":"evt-test-1","type":"lead.created"}`. Первый запрос с корректной подписью получает 202 и ставится в маршрут `leads`; повтор с тем же id получает 200 и не создаёт вторую запись. Ошибочная подпись получает 401, некорректная структура — 400. `order.created` направляется в `orders`, остальные корректные типы — в `other`.

## Учётные данные и параметры
Нужны Crypto credential с секретом подписи и отдельный PostgreSQL credential. Измените путь и сопоставление типов событий. Идентификатор события должен быть уникальным в пределах этого приёмника. В таблицу сохраняются только id, тип, маршрут, время и состояние; остальные поля payload намеренно не сохраняются.

## Ограничения
Это приёмник и маршрутизируемая очередь в PostgreSQL, а не готовая интеграция с CRM: внешний обработчик очереди нужно подключить самостоятельно. Хранение уникальных id даёт дедупликацию при параллельных запросах, но не гарантирует «ровно один раз» для последующих внешних действий; потребителю нужна собственная идемпотентность. Если поставщик подписывает timestamp или использует другую схему, требуется адаптация. Установите срок хранения id и проверьте хранение входящих данных в истории n8n. В изолированном тесте проверены HMAC на фиктивных данных, ветки корректной и ошибочной подписи и 20 параллельных SQL-вставок; дополнительно проверены HTTP-ответы 202/200/401/400 через настоящий webhook в закрытой тестовой сети. Реальный внешний источник не тестировался.

## Совместимость и проверка
Проверка: 10 ноября 2026 г.; n8n 2.42.6, узлы из стандартной поставки. Проверены импорт JSON и выполнение в изолированной тестовой среде с фиктивными данными. Никакие реальные API и чаты при проверке не использовались. В других версиях проверьте соответствующие версии узлов. Импортируйте сценарий выключенным; перед запуском настройте доступы и выполните собственный тест.

При повторном импорте через CLI совпадающий ID может перезаписать существующий workflow: для новой копии измените или удалите ID в копии файла перед импортом.

Учётные данные в файлах не содержатся. Ограничивайте доступ к workflow, результатам выполнения и журналам; в настройках n8n задайте хранение и удаление данных в соответствии с вашими требованиями.