Почему у автоматизации ломается не API, а входные данные

Почему у автоматизации ломается не API, а входные данные

90% «магических» поломок в n8n/Make не в интеграциях, а в грязном входе: пустые поля, разные форматы даты, дубли, неожиданный массив вместо строки. Поэтому первый узел после триггера — не логика, а нормализация.

Сценарий: триггер → Set/Function → проверка обязательных полей → маршрутизация. Сразу приводим телефон, email, сумму, UTM и ID к одному виду. Если поле пустое — не пускаем дальше, а кладём в отдельную ветку на ручную проверку.

Дальше ставим защиту от дублей: сохраняем ключ события в таблицу или KV-хранилище и перед записью проверяем, не приходил ли он уже. Это дешевле, чем потом чистить CRM, таблицы и спай-лог после повторного запуска.

Ещё одна точка боли — ошибки на внешнем сервисе. Таймауты, 429, битые JSON. Здесь нужны retry с паузой, лимит на повтор и отдельный error workflow, который не молча падает, а пишет в чат с payload и шагом, где всё сломалось.

Если автоматизация живёт только на «идеальных» данных, она уже не автоматизация. Сначала чистый вход, потом интеграции, потом масштабирование.