Перейти к содержанию

Заявка с сайта в CRM через n8n: webhook и валидация

Обновлено: 2026-05-29

Открыть мой план

Один из самых полезных workflow — принять заявку с сайта и передать её в CRM без ручного копирования. n8n работает как прослойка: webhook, очистка данных, проверка дублей, CRM API и уведомление менеджера.

Схема workflow

Webhook → Normalize Lead → Validate Required Fields → Check Duplicate → Create/Update CRM Lead → Notify Manager → Save Log

Нормализация

name: {{ $json.name || $json.full_name || "Без имени" }}
email: {{ ($json.email || "").trim().toLowerCase() }}
phone: {{ $json.phone || null }}
source: website
created_at: {{ $now.toISO() }}

Валидация

Если нет email и телефона, заявку лучше отправить в ветку ошибок, а не создавать пустой лид. Менеджеру можно отправить alert с сырым payload или ссылкой на execution.

CRM API

Если у CRM есть готовая нода — используйте её. Если нет, подключите HTTP Request: endpoint создания лида, auth, JSON body и обработка ответа. Для 401 проверяйте credential, для 429 — лимиты.

Архитектура production workflow

Для сценария Заявка с сайта в CRM через n8n: webhook и валидация полезно строить workflow не как одну длинную цепочку, а как понятный конвейер: вход, нормализация, проверка, основное действие, запись результата и обработка ошибок. Тогда статью можно использовать как инструкцию внедрения, а не как набор разрозненных советов.

СлойЗадачаЧто логировать
Triggerполучить событие от webhookevent_id, source, время получения
Normalizeпривести поля к единой схемеid события или записи, source, created_at, status, payload_hash
Validateотсечь пустые, повторные и рискованные входыпричину отказа и исходный payload_hash
Actionвыполнить главное действие рецептаid созданной/обновлённой записи
Notifyсообщить человеку или системе результатканал, статус, ссылка на execution

Минимальная схема данных

Не начинайте рецепт с настройки красивых уведомлений. Сначала определите контракт данных: какие поля приходят, какие обязательны, где создаётся уникальный ключ и что считается успешным результатом. Для этой статьи базовый контракт можно начать с таких полей:

  • id события или записи
  • source
  • created_at
  • status
  • payload_hash
  • email
  • phone
  • lead_source
  • owner
  • method

Если поля отличаются у разных источников, добавьте отдельную нормализационную ноду сразу после trigger. Это снижает количество выражений в последующих нодах и упрощает поддержку.

Проверка на реальных крайних случаях

  • пустой payload или форма без обязательного поля
  • повторная доставка одного и того же события
  • частичный успех: внешняя запись создана, но уведомление не отправилось
  • медленный API или временный 429/5xx
  • ручной повтор старого execution через неделю после первого запуска

MVP и production-версия рецепта

Рецепт Заявка с сайта в CRM через n8n: webhook и валидация не должен конкурировать со справочником нод. Здесь важен готовый сценарий: какие ноды соединить, какие данные передать и как проверить бизнес-результат.

УровеньЧто включитьЧто пока не делать
MVPWebhook/Trigger, нормализация, основное действие, короткий ответсложные retry, multi-tenant логику, лишние ветки
Productionidempotency, error workflow, лог статусов, ручная очередь, alertхранить токены в тексте нод или логировать полный payload
Scaleочередь, лимиты, batch processing, SLA-метрикираздувать один workflow до нечитабельной схемы

Как понять, что рецепт готов

  1. Есть один владелец процесса и понятный критерий успеха: лид создан, письмо отправлено, документ сохранён, задача закрыта.
  2. Повторный запуск с тем же payload не создаёт дубль.
  3. Ошибочный payload не теряется, а попадает в manual review или alert.
  4. Все внешние API вызываются через credentials, а не через токен в plain text.
  5. К рецепту привязан готовый шаблон в разделе workflow или указано, почему шаблон не нужен.

Что читать дальше

Смотрите Webhook, HTTP Request и error alerts.

Как адаптировать рецепт

Не копируйте workflow механически. Сначала сохраните архитектуру, затем замените сервисы под свой стек: Telegram на Slack, Google Sheets на PostgreSQL, готовую CRM-ноду на HTTP Request. Важно, чтобы остались нормализация, валидация, логирование и обработка ошибок.

  • Определите trigger и формат входных данных.
  • Сразу приведите поля к единому формату.
  • Добавьте проверку дублей или idempotency, если действие нельзя повторять.
  • Сделайте alert для критичных ошибок.

Критерий готовности

Рецепт готов к production, когда он успешно проходит не только «идеальный» пример, но и пустой input, дубль, ошибку API и повторный запуск. Если эти случаи не проверены, workflow лучше считать прототипом.