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

Работа с данными в n8n: items, JSON и нормализация

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

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

В n8n данные проходят по workflow как набор items. Каждый item обычно содержит JSON: строку таблицы, сообщение Telegram, payload webhook, ответ API или подготовленный объект для следующей ноды. Большинство ошибок возникает не из-за интеграций, а из-за неверного ожидания формы данных.

Что такое item

Если Google Sheets вернул 50 строк, дальше пойдёт 50 items. Если HTTP Request вернул один объект, дальше пойдёт один item. Если API вернул массив внутри data, его часто нужно превратить в отдельные items.

Пример нормализованного item:

{
  "name": "Анна",
  "email": "anna@example.com",
  "source": "telegram",
  "status": "new"
}

Нормализация входа

Сразу после trigger добавляйте Set/Edit Fields и приводите данные к стабильному виду:

email: {{ ($json.email || $json.contact?.email || "").toLowerCase() }}
phone: {{ $json.phone || $json.contact?.phone || null }}
created_at: {{ $now.toISO() }}

Так следующие ноды работают с понятными полями, а не с разными вариантами сырого JSON.

Массивы и вложенные поля

Вложенные поля читаются через точку: {{ $json.user.name }}. Массивы — через индекс: {{ $json.items[0].price }}. Если массив может быть пустым, используйте безопасный доступ: {{ $json.items?.[0]?.price || 0 }}.

Set, Code и Merge

Set/Edit Fields подходит для простого переименования и добавления полей. Code node нужен для циклов, группировки и сложной фильтрации. Merge объединяет ветки, но требует внимания к ключам и item linking.

Практический контекст для внедрения

Эта страница полезна не как абстрактная справка, а как рабочая инструкция под тему «Работа с данными в n8n: items, JSON и нормализация» в практическом внедрении n8n. Перед изменением workflow зафиксируйте источник события: входные данные по теме working with data: webhook, schedule, ручной запуск или событие внешнего сервиса. Так проще отделить ошибку данных от ошибки настройки n8n и не превратить исправление в набор случайных правок.

Для production-версии заранее назначьте владельца процесса, точку восстановления и критерий успешного запуска. Главный риск для этой темы: пустые входы, дубли, разные форматы payload, неопределённый владелец процесса. Его лучше закрывать не дополнительными нодами, а явным контрактом входных данных, idempotency-ключом, логированием решения и отдельной веткой обработки ошибок.

СлойЧто проверитьПочему это важно
Входpayload, внешний ID, timestamp, источник событиябез этого невозможно отличить новый item от повтора
Логикаусловия IF/Switch, mapping полей, fallbackошибка часто появляется не в ноде, а в переходе между ветками
Выходстатус операции, запись audit trail, ссылка на executionпосле запуска нужно быстро понять, что workflow сделал с конкретным объектом
Эксплуатацияsuccessful executions, skipped items, retry count, error branch usageметрики показывают деградацию раньше, чем пользователи начинают жаловаться

Как проверить качество страницы на практике

  • Соберите один тестовый пример по теме «Работа с данными в n8n: items, JSON и нормализация» и прогоните его через workflow вручную.
  • Проверьте пустой вход, повтор того же события и ошибку внешнего API.
  • Убедитесь, что в execution видно решение workflow: почему ветка была выбрана и какой внешний объект изменён.
  • Добавьте ссылку на эту страницу в runbook, если сценарий будет поддерживать не только автор автоматизации.

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

Для синтаксиса откройте выражения, для сложных преобразований — JavaScript.

Чеклист внедрения

Перед публикацией workflow проверьте его на нескольких реальных примерах данных, а не только на одном успешном тесте. Убедитесь, что обязательные поля валидируются, пустые значения не ломают выражения, а каждая ветка имеет понятное завершение.

  • Ноды названы по действию, а не по типу.
  • Входные данные нормализованы в начале workflow.
  • Есть fallback для неожиданных статусов и пустых полей.
  • Ошибки пишутся в execution и при необходимости отправляются в alert.

Как понять, что тема нужна

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

Практическое применение страницы

Материал «Работа с данными в n8n: items, JSON и нормализация ¶» лучше использовать как точку входа в рабочий маршрут, а не как изолированную справку. Перед внедрением выберите конкретный процесс, источник данных, владельца и ожидаемый результат. Это помогает быстро понять, какая страница базы нужна дальше: рецепт, диагностика, интеграция, нода или production-playbook.

Для любой автоматизации в n8n полезно заранее описать входной item, обязательные поля, внешние сервисы, write-действия и способ отката. Если эти детали не зафиксированы, даже простой workflow может стать неуправляемым: дублирует заявки, теряет часть items, отправляет уведомления не тем людям или ломается при изменении формата API.

Минимальный чеклист

  • Определите, что является успешным результатом и кто его подтверждает.
  • Проверьте happy path, пустой вход, повтор события и сбой внешнего сервиса.
  • Добавьте логирование execution id, source, external id и статуса без секретов.
  • Свяжите страницу с ближайшим рецептом, ошибкой или playbook.
  • Навигатор — открыть связанный материал для проверки контекста.
  • Диагностика — открыть связанный материал для проверки контекста.
  • Рецепты — открыть связанный материал для проверки контекста.
  • Playbooks — открыть связанный материал для проверки контекста.