---
title: "Items в n8n: что передаётся между нодами - Nodbot"
source_url: "https://nodbot.ru/basics/items/"
canonical_url: "https://nodbot.ru/basics/items/"
language: "ru"
content_type: "KnowledgePage"
section: "basics"
generated_at: "2026-05-30"
word_count_source: 1009
---

# Items в n8n: что передаётся между нодами

## AI summary

Объяснение items в n8n: JSON, binary, массивы, item count, Split in Batches, Merge и типовые ошибки маппинга.

## Best used for

Страница объясняет «Items в n8n: что передаётся между нодами - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Что проверять
- Практический пример
- Практический минимум после изучения темы
- Пример безопасного входного контракта
- Критерий готовности
- Практический контекст для внедрения
- Как проверить качество страницы на практике
- Что добавить перед публикацией или запуском

## Source outline

# Items в n8n: что передаётся между нодами

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

## Что проверять

- Сколько items пришло в ноду.
- Где лежит поле: $json.phone , nested object или binary.
- Не потерялся ли item linking после Code node.
- Нужно ли объединять ветки через Merge.

## Практический пример

```
{{$json.phone}}
{{$items("Previous node")[0].json.email}}
```
Глубже: item linking и работа с данными .

## Практический минимум после изучения темы

Страницу «Items в n8n» лучше использовать как практический чеклист, а не как справку. Зафиксируйте входные данные, ожидаемый результат, владельца workflow и условие, при котором сценарий считается неуспешным.

Базовый источник для проверки: входной item по теме «Items в n8n»: источник события, внешний ID, время получения и нормализованные поля. Главный риск — принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость.

- Слой | Что зафиксировать | Зачем
- Вход | входной item по теме «Items в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам
- Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Items в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}
```

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

- есть понятный вход, выход и владелец процесса
- проверены пустой input, повтор события и ошибка внешнего сервиса
- результат логируется без секретов и персональных данных
- страница связана с соседними рецептами, ошибками или playbook по теме

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

Эта страница полезна не как абстрактная справка, а как рабочая инструкция под тему «Items в n8n: что передаётся между нодами» в практическом внедрении n8n. Перед изменением workflow зафиксируйте источник события: входные данные по теме items: 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 | метрики показывают деградацию раньше, чем пользователи начинают жаловаться

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

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

## Что добавить перед публикацией или запуском

Чтобы материал по теме «Items в n8n: что передаётся между нодами» не оставался короткой справкой, используйте его как чеклист подготовки workflow. Минимально зафиксируйте источник данных: входные данные по теме items: webhook, schedule, ручной запуск или событие внешнего сервиса; затем опишите ожидаемый результат, владельца процесса, способ отката и метрики контроля. Это превращает страницу из карточки в практическую инструкцию, которую можно дать разработчику, интегратору или владельцу процесса.

Особое внимание стоит уделить риску: пустые входы, дубли, разные форматы payload, неопределённый владелец процесса. Для n8n это важно, потому что одна и та же ошибка может выглядеть как проблема ноды, credentials, внешнего API, формата payload или инфраструктуры. Перед production-публикацией лучше проверить симптом на минимальном workflow, а уже потом переносить исправление в основной сценарий.

- Добавьте один реальный пример входного payload без секретов и персональных данных.
- Опишите happy path, пустой вход, повтор события и ошибку внешнего сервиса.
- Подключите наблюдаемость: successful executions, skipped items, retry count, error branch usage.
- Укажите, где хранится audit trail и кто принимает решение при неоднозначном результате.
- Проверьте, что страница связана внутренними ссылками с рецептом, ошибкой, нодой или playbook по этой же теме.

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

- Диагностика n8n
- Workflow-шаблоны
- Карта базы знаний

## Практическое правило

Перед внедрением сформулируйте вход, выход и ошибочную ветку. В n8n большинство проблем появляется не из-за одной ноды, а из-за неявного контракта данных: где-то поле называется иначе, где-то приходит массив вместо объекта, где-то повторяется событие. Поэтому даже базовая тема должна заканчиваться проверкой на реальном payload.

## Как проверить понимание

- можете объяснить, какие данные входят в ноду и что выходит дальше;
- знаете, что случится при пустом item или отсутствии поля;
- понимаете, где добавить IF/Switch, Code node или Stop and Error;
- можете найти execution и повторить проблему.
Если нужен готовый сценарий, переходите в workflows. Если уже есть симптом, открывайте diagnostics, чтобы не смешивать обучение и troubleshooting.

## Практический минимум перед публикацией

Перед тем как использовать материал в работе, проверьте три вещи: есть ли понятный входной payload, есть ли ожидаемый выход и описана ли ветка ошибки. Для n8n это важнее длинного описания интерфейса: workflow может выглядеть правильно, но ломаться на пустом item, повторном webhook, истёкшем token или несовпадении структуры JSON.

Если страница используется как инструкция для команды, добавьте рядом ссылку на импортируемый workflow, тестовый payload и владельца процесса. Если страница используется как диагностика, фиксируйте execution ID, внешний request ID и одно конкретное исправление. Если это карта внедрения, не запускайте всё сразу: сначала тестовая воронка, затем ограниченный production, затем мониторинг ошибок.

## Как не смешивать сценарийы

Эта страница отвечает за свой участок задачи. Подробные параметры нод остаются в справочнике нод, бизнесовый сценарий — в рецептах и use-cases, готовые JSON — в workflows и kits, а симптомы поломок — в diagnostics. Такое разделение помогает пользователю идти по маршруту и не читать одно и то же на разных URL.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.