API часто возвращает не одну запись, а список: товары, заявки, документы. Чтобы обработать каждую запись в n8n, важно найти именно массив данных и превратить его элементы в отдельные items. В этой инструкции получим десять учебных публикаций, проверим список, разделим его через Split Out и оставим четыре поля для каждой строки.
Результат инструкции
Соберём цепочку Manual Trigger → Get Posts → Check List → Split Posts → Build Rows. Если список не подходит, Check List направляет выполнение в Reject List. На выходе - десять строк с post_id, user_id, title и body_length. Ничего не записываем в CRM, не отправляем людям и не вызываем модель: результат остаётся в выполнении n8n для проверки.
Источник - публичный учебный API JSONPlaceholder с вымышленными данными. Одна публикация в предыдущей инструкции превращалась в один результат. Здесь покажем, как не потерять остальные девять записей и не повторить первую десять раз.
Предыдущий шаг: HTTP Request и проверка одного JSON
Что понадобится
- Запущенный n8n с доступом в редактор; пример проверен на версии 2.42.4.
- Доступ к интернету у самого n8n. Для JSONPlaceholder регистрация и API-ключ не нужны.
- Новый пустой workflow и скачанный JSON из следующего шага. Не вставляйте учебные узлы в рабочую схему.
- Для первой проверки в Windows - PowerShell и curl.exe. Остальная работа выполняется в редакторе.
Установить n8n локально через Docker
Шаг 1. Получите список публикаций
В PowerShell выполните запрос ниже. Параметр userId=1 просит публикации одного учебного пользователя. Это операция чтения, без отправки тела запроса.
curl.exe --include --max-time 20 "https://jsonplaceholder.typicode.com/posts?userId=1"При нашей проверке пришёл HTTP 200 и массив из десяти объектов с id от 1 до 10. Начало массива обозначается [, а каждый объект внутри содержит userId, id, title и body. Если ответ не пришёл, сначала проверьте адрес и сеть. Не отключайте проверку TLS-сертификата.
Шаг 2. Скачайте готовую схему
Скачать n8n-json-array-demo.json
Сохраните полный JSON как файл .json. Если браузер показывает текст, сохраните страницу. В схеме шесть узлов, нет credentials, секретов или включённого автоматического запуска. Она делает один HTTP-запрос, а не десять.
Шаг 3. Импортируйте в новый workflow
Нажмите Overview → Create workflow. Откройте файл в текстовом редакторе, скопируйте всё, щёлкните свободную область пустой схемы и нажмите Ctrl+V. Можно использовать Import from File через меню More actions, если этот пункт доступен. Проверьте имя ezgpt-json-array-demo и наличие шести узлов.
Нажмите Zoom to Fit. Ветка true у Check List должна идти в Split Posts, затем в Build Rows. Ветка false - только в Reject List. Не соединяйте отказ с обработкой списка.
Шаг 4. Настройте запрос со своим параметром
Дважды щёлкните по значку Get Posts. Method = GET, Authentication = None. В поле URL должен быть базовый адрес без добавленного вручную ?userId=1:
https://jsonplaceholder.typicode.com/postsSend Query Parameters включено. В режиме Using Fields Below должна быть одна пара: Name = userId, Value = 1. Не добавляйте такой же параметр второй раз в URL. Send Headers и Send Body для упражнения выключены.
В Options → Response оставьте Response Format = JSON, Include Response Headers and Status включённым, Never Error выключенным. Timeout = 15000 мс ограничивает ожидание начала ответа; это не лимит времени всего workflow. Ignore SSL Issues не включайте.
n8n: HTTP Request и Query Parameters
Шаг 5. Найдите массив внутри одного item
Нажмите Execute step в Get Posts и откройте OUTPUT → JSON. Наш узел возвращает один item с полным HTTP-ответом. Внутри поля body находятся десять публикаций. Один item здесь не означает, что API вернул только одну публикацию.
{
"body": [
{ "userId": 1, "id": 1, "title": "заголовок 1", "body": "текст 1" },
{ "userId": 1, "id": 2, "title": "заголовок 2", "body": "текст 2" }
],
"statusCode": 200
}Это сокращённая иллюстрация структуры: показаны только две записи, без headers. Реальный ответ содержит десять. Массив находится в $json.body. Не разбивайте headers или весь объект ответа. Если выключить полный ответ, структура выхода HTTP Request изменится; инструкция рассчитана именно на включённый переключатель.
Шаг 6. Проверьте список до разделения
Откройте Check List - узел If. Левое значение в режиме Expression, тип Boolean, оператор is true. В импортированном workflow уже стоит выражение ниже. В редактор выражений вставляйте {{ ... }} без служебного =, который есть в JSON-файле схемы.
{{ $json.statusCode === 200 && Array.isArray($json.body) && $json.body.length > 0 && $json.body.length <= 10 && $json.body.every(p => p !== null && Number.isSafeInteger(p.id) && p.id > 0 && p.userId === 1 && typeof p.title === 'string' && p.title.trim().length > 0 && typeof p.body === 'string' && p.body.trim().length > 0) }}Проверка принимает HTTP 200 и массив от одной до десяти публикаций. Каждый элемент должен иметь положительный целочисленный id, userId = 1, непустые строковые title и body. Если неверна хотя бы одна запись, отклоняется весь список до Split Out. Это правила учебного прототипа, а не универсальный контракт для всех API.
Ветка false подключена к Stop And Error с именем Reject List. Пустой список здесь считается отказом, чтобы его было легко увидеть в тесте. В рабочем поиске пустой результат может быть нормальным: для него нужно заранее выбрать отдельную обработку, а не объявлять любой [] ошибкой.
Шаг 7. Разделите body через Split Out
Откройте Split Posts. Это узел Split Out. Fields To Split Out = body, Include = No Other Fields. В Options добавлена Destination Field Name = post. Остальные параметры менять не нужно.
Выполните узел через Execute step после успешного запроса. OUTPUT должен содержать десять items. В каждом теперь одно поле post с конкретной публикацией. Первая запись выглядит так:
{
"post": {
"userId": 1,
"id": 1,
"title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
"body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}
}Путь к id теперь $json.post.id, а не $json.body[0].id. Мы выбрали имя post специально, чтобы не путать оболочку HTTP-ответа и текст публикации body. Заголовки ответа не копируются в каждую строку благодаря No Other Fields.
n8n: Split Out и Destination Field Name
Шаг 8. Оставьте четыре поля в каждой строке
Откройте Build Rows - Edit Fields (Set). Mode = Manual Mapping. В Fields to Set заданы четыре поля, все значения в режиме Expression:
- post_id: Number, {{ $json.post.id }}.
- user_id: Number, {{ $json.post.userId }}.
- title: String, {{ $json.post.title }}.
- body_length: Number, {{ $json.post.body.length }}.
Include Other Input Fields выключен: на выходе не должно остаться вложенного post. В Settings не включайте Execute Once - иначе узел обработает только первый входной item. Свойство length здесь измеряет длину строки JavaScript, не количество слов или байтов.
n8n: Edit Fields и выходные поля
Шаг 9. Запустите всю цепочку и сравните строки
Вернитесь на схему и нажмите Execute workflow. После завершения откройте Build Rows → OUTPUT → Table. Должно быть десять строк и четыре колонки. Затем в JSON сравните первую и последнюю записи. Ниже показаны только эти две строки, не весь результат:
[
{
"post_id": 1,
"user_id": 1,
"title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
"body_length": 158
},
{
"post_id": 10,
"user_id": 1,
"title": "optio molestias id quia eum",
"body_length": 129
}
]В каждой строке user_id = 1, но post_id и заголовок меняются. Для первой публикации при проверке body_length = 158, для десятой - 129. Главное - соответствие исходному ответу: если учебный API изменит текст, длины тоже изменятся. Не подменяйте данные фиксированными числами ради совпадения примера.
Для Edit Fields в этой схеме не нужен отдельный цикл: узел обрабатывает входные items. Split Out разделяет массив, но не управляет скоростью запросов, не загружает дополнительные страницы и не устраняет дубли.
n8n: обработка нескольких items и Execute Once
Шаг 10. Проверьте пустой список
В Get Posts временно измените Value у параметра userId с 1 на 999. Запустите весь workflow. В нашем тесте API вернул HTTP 200 с body = []. Check List должен выбрать false, а Reject List - завершить выполнение ошибкой с сообщением Expected HTTP 200 and 1-10 posts for user 1 with numeric id and nonempty title/body.
Split Posts и Build Rows при этом не должны выполняться. Это проверка нашей политики пустого результата, не сбой API. После теста верните userId = 1.
Шаг 11. Проверьте другой набор и неправильную структуру
Сначала установите userId = 2 и выполните цепочку заново. Список другого пользователя тоже должен попасть в Reject List: правило userId = 1 не прошло. Верните значение 1.
Затем временно выключите Send Query Parameters и замените URL на адрес одной публикации:
https://jsonplaceholder.typicode.com/posts/1Повторите Execute workflow. Ответ 200 содержит объект, а не массив, поэтому Check List должен остановить обработку через Reject List. Не исправляйте этот случай заменой body на body[0]: у объекта нет списка записей. Для одной публикации подходит предыдущая инструкция HTTP Request.
Шаг 12. Восстановите схему и проверьте все десять id
Верните URL https://jsonplaceholder.typicode.com/posts, включите Send Query Parameters и оставьте единственную пару userId = 1. Выполните workflow ещё раз. В последнем результате Build Rows проверьте:
- Десять items, ровно четыре поля в каждой строке.
- Все user_id равны 1, заголовки соответствуют исходным публикациям.
- Нет headers и вложенного post; Reject List не запускался.
- post_id идут от 1 до 10 без повтора первой записи.
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]Дождитесь сохранения. Для Manual Trigger публикация workflow не требуется. При проверке используйте данные последнего выполнения: старые значения в OUTPUT могут остаться после неудачного теста и не доказывают, что новая цепочка завершилась успешно.
Если результат отличается
| Симптом | Что проверить | Ожидаемый результат |
|---|---|---|
| Один item в HTTP Request | Полный ответ и поле body | Внутри body десять объектов |
| Split Out не находит список | Field to Split Out = body | Разделяется массив, не headers |
| После Split Out другой путь | Destination Field Name = post | $json.post.id |
| Первая запись повторяется | Выражения Build Rows | Используют текущий $json.post |
| На выходе одна строка | Settings → Execute Once | Выключено, десять items |
| Reject List при HTTP 200 | Тип, длина и содержимое body | Массив публикаций userId = 1 |
Перед обработкой настоящих заявок
Подставьте API своего сервиса только после проверки его документации, credentials и прав на чтение. Найдите поле списка, например data или results, и адаптируйте Check List, Split Out и выражения. Не считайте, что параметры JSONPlaceholder подходят вашей CRM. Ограничение в десять записей лишь останавливает слишком большой ответ: оно не обрезает список и не заменяет пагинацию.
Не подключайте массовую рассылку, платежи или удаление сразу после Build Rows. Десять items способны превратиться в десять действий, а повторный запуск - повторить их. Для рабочей интеграции нужны проверка дублей, ограничения нагрузки и подтверждение опасных операций. Split Out не гарантирует выполнение ровно один раз и не исправляет права доступа.
Дальше: создание ИИ-агента в n8n
Что проверено редакцией
9 октября 2026 года пример проверен на n8n 2.42.4 в отдельной тестовой базе. Выполнены четыре реальных HTTP-сценария: десять публикаций, пустой список, другой пользователь и объект вместо массива. Все 22 автоматические проверки результата и десять отдельных проверок выражения прошли. В локальном редакторе схема импортирована в новый workflow и вручную вернула десять строк; параметры Split Out и Edit Fields проверены в интерфейсе. Существующие схемы не изменялись. n8n Cloud, закрытые API, запись в таблицы, реальные рассылки, пагинация и ограничение частоты запросов не тестировались. Обложка - редакционная иллюстрация, не снимок интерфейса.
Частые вопросы
Почему HTTP Request показывает один item, хотя в JSON десять записей?
В нашей схеме включён полный HTTP-ответ. Один item содержит body с массивом из десяти публикаций. Split Out разделяет именно body и создаёт десять отдельных items. Количество items и длина вложенного массива - разные величины.
Что указывать в Field to Split Out?
Поле, в котором действительно находится массив. В этой схеме это body. Если у вашего API список вложен глубже, сначала проверьте фактический JSON и адаптируйте путь. Заголовки HTTP или весь объект ответа разбивать не нужно.
Нужен ли Loop Over Items после Split Out?
Для Edit Fields в нашем примере нет: он обрабатывает полученные items. Loop Over Items может понадобиться для контролируемых пакетов или последовательной обработки, но Split Out сам по себе не ограничивает частоту внешних запросов.
Почему пустой массив вызывает ошибку?
Так настроен учебный Check List: он принимает от одной до десяти записей. В реальном поиске пустой список может быть нормальным результатом. Выберите для него отдельную ветку, если отсутствие записей не является ошибкой вашего процесса.
Можно ли сразу записывать результат в CRM или отправлять сообщения?
Сначала проверьте все строки на учебных данных. Добавление изменяющего узла может выполнить действие для каждого item, а повторный запуск - повторить его. Настройте минимальные права, защиту от дублей и подтверждение, прежде чем работать с реальными данными.
