Выгрузка называет поле order_id, а принимающий API ждёт id. Значение менять не нужно: нужно переименовать ключ. Сделаем это через штатный Rename Keys в n8n и проверим, что строки не стали числами, нулевая сумма не пропала, а уже существующее поле не было перезаписано незаметно.
Результат инструкции
Соберём ручной workflow из пяти узлов. На входе будут три вымышленных заказа с полями order_id, client_name, sum_minor, active и note. На выходе получим те же три заказа с полями id, customer, amount_minor, enabled и note.
Новые названия согласованы только для этого учебного примера. Никакой реальный API не вызывается, записи в CRM и файлы не создаются. Rename Keys выполняет само переименование, а Code до и после него проверяет договор данных и сохранность значений. Нейросеть и API-ключи не нужны.
Что понадобится
- Работающий n8n и отдельный новый workflow. Проверено на n8n 2.42.4, Rename Keys версии 1.
- Code с JavaScript для учебного источника и двух проверок. Все примеры можно повторить без внешнего сервиса.
- Четыре пары старых и новых имён. В этой инструкции работаем только с полями верхнего уровня, без Regex и вложенных путей.
Установить n8n локально через Docker
Шаг 1. Импортируйте workflow
Скачать n8n-rename-fields.json
Создайте новый workflow и импортируйте JSON через Import from File в меню редактора. Проверьте схему:
Manual Trigger → Sample Rows → Check Input → Rename Fields → Check OutputRename Fields — переименованный штатный Rename Keys. Sample Rows, Check Input и Check Output — Code. В скачиваемой схеме нет credentials и чужого ID, она неактивна. Запускайте её вручную от Manual Trigger.
Шаг 2. Подготовьте исходные записи
В Sample Rows выберите Mode: Run Once for All Items, Language: JavaScript. Вставьте:
const rows = [
{"order_id":"001","client_name":"Альфа","sum_minor":150000,"active":true,"note":null},
{"order_id":"002","client_name":"Бета","sum_minor":0,"active":false,"note":"Самовывоз"},
{"order_id":"003","client_name":"Гамма","sum_minor":49900,"active":true,"note":""}
];
return rows.map(json => ({ json }));Выполните источник. Должны появиться три items, по одному заказу в каждом. order_id содержит строку 001 с ведущими нулями, sum_minor — число копеек, active — boolean. Во втором заказе специально стоят 0 и false, а note первого равен null.
Скачать исходные и ожидаемые данные n8n-rename-demo.json
Файл содержит разделы input и expected для сверки. Workflow не загружает его автоматически: источником служит код Sample Rows. Если отправить вместо трёх items один объект с массивом input, эта схема не будет соответствовать описанному договору.
Шаг 3. Зафиксируйте типы и незанятые имена
До переименования в каждой записи должно быть ровно пять исходных полей. Полей id, customer, amount_minor и enabled пока быть не должно. Иначе переименование может затереть значение, которое уже лежит под новым именем.
| Проверяем | Ожидается | Почему важно |
|---|---|---|
| order_id | Уникальная строка из трёх цифр | Сохраняем 001, не число 1 |
| sum_minor | Целое неотрицательное число | 0 допустим, строка не допустима |
| active и note | Boolean; строка или null | Не теряем false и null |
| Новые имена полей | Ещё отсутствуют | Исключаем перезапись назначения |
Rename Keys не является проверкой схемы. Зелёное выполнение само по себе не говорит, что все нужные ключи найдены или что новое имя свободно. Поэтому следующая проверка обязательна для этого примера.
Шаг 4. Проверьте вход до переименования
В Check Input задайте Run Once for All Items, JavaScript и вставьте:
const items = $input.all();
if (items.length < 1 || items.length > 20) throw new Error('row_count_invalid');
const ids = new Set();
for (const { json: row } of items) {
if (Object.keys(row).sort().join('|') !== 'active|client_name|note|order_id|sum_minor') {
throw new Error('input_fields_invalid');
}
if (typeof row.order_id !== 'string' || !/^\d{3}$/.test(row.order_id) || ids.has(row.order_id)) {
throw new Error('id_invalid_or_duplicate');
}
if (typeof row.client_name !== 'string' || !row.client_name.trim() || row.client_name.length > 100) {
throw new Error('client_name_invalid');
}
if (!Number.isSafeInteger(row.sum_minor) || row.sum_minor < 0) throw new Error('sum_minor_invalid');
if (typeof row.active !== 'boolean') throw new Error('active_invalid');
if (row.note !== null && (typeof row.note !== 'string' || row.note.length > 200)) {
throw new Error('note_invalid');
}
ids.add(row.order_id);
}
return items.map(item => ({ json: item.json }));На исходных данных дальше пройдут три записи без изменений. Проверка отклоняет неизвестные и пропущенные поля, повтор ID, числовой ID, текстовую сумму, отрицательное число, строку вместо boolean и неподходящий note. Поле с новым именем тоже считается лишним и вызывает input_fields_invalid.
Ограничение от 1 до 20 записей и длины строк — учебные правила, не ограничения Rename Keys. Проверка не исправляет значения и не решает, какой из двух конфликтующих ID правильный. В Settings всех узлов оставьте On Error: Stop Workflow; Continue On Fail, Always Output Data, Execute Once и Retry On Fail не включайте.
Шаг 5. Добавьте четыре пары имён
В Rename Fields откройте Keys и через Add new key добавьте четыре пары. Имена вводятся обычным текстом:
| Current Key Name | New Key Name | Что меняется |
|---|---|---|
| order_id | id | Имя идентификатора |
| client_name | customer | Имя поля клиента |
| sum_minor | amount_minor | Имя поля суммы |
| active | enabled | Имя boolean-поля |
В Current Key Name нужно написать order_id, а не значение 001 и не выражение, возвращающее это значение. В New Key Name пишите id. Сумму не делим на 100: sum_minor и amount_minor в примере означают одни и те же копейки.
У всех четырёх пар разные исходные имена и разные назначения. Не используйте одно New Key Name для двух полей: они начнут претендовать на одно место. Наш Check Output заметит неправильную итоговую структуру, но лучше исправить пары до запуска.
Шаг 6. Оставьте Regex выключенным
В Additional Options не добавляйте Regex. Для четырёх известных полей достаточно явных пар. Регулярное выражение может затронуть несколько ключей, включая уже переименованные, поэтому в этой инструкции оно не используется.
Также не добавляйте точки в имена: customer.name — не то же самое, что плоское customer. Узел поддерживает пути, но у вложенной структуры другой договор. Мы не строим вложенные объекты, не меняем имена ключей внутри массивов и не проверяем массовое переименование регулярными выражениями.
Шаг 7. Проверьте выход Rename Fields
Запустите всю схему от Manual Trigger и откройте Rename Fields. Ожидаются три items. У первой записи должны быть такие поля и значения, порядок отображения ключей может отличаться:
{
"note": null,
"id": "001",
"customer": "Альфа",
"amount_minor": 150000,
"enabled": true
}Ключей order_id, client_name, sum_minor и active больше нет. Вместо них появились id, customer, amount_minor и enabled. note сохранился, поскольку мы его не переименовываем. У второй записи amount_minor остаётся числом 0, enabled — boolean false.
Переименование не преобразует единицы измерения, не переводит текст и не делает ID числом. Если исходная сумма пришла строкой, проверка остановится до узла. Удалять эту проверку ради успешного статуса не нужно.
Шаг 8. Сравните результат с исходными значениями
В Check Output установите Run Once for All Items и JavaScript. Вставьте:
const items = $input.all();
const source = $('Check Input').all();
if (items.length !== source.length) throw new Error('output_count_mismatch');
for (let i = 0; i < items.length; i++) {
const row = items[i].json;
const old = source[i].json;
const expected = {
id: old.order_id, customer: old.client_name,
amount_minor: old.sum_minor, enabled: old.active, note: old.note
};
if (Object.keys(row).sort().join('|') !== 'amount_minor|customer|enabled|id|note') {
throw new Error('output_fields_mismatch');
}
if (Object.entries(expected).some(([key, value]) => row[key] !== value)) {
throw new Error('output_value_or_order_mismatch');
}
}
return items.map(item => ({ json: item.json }));Код проверяет количество записей, точный набор новых полей, порядок items и каждое значение относительно Check Input. Сравнение строгое: строка "0" не равна числу 0, строка "false" не равна boolean false. В этой схеме все поля скалярные, поэтому такого сравнения достаточно. Для массивов и вложенных объектов нужна другая проверка.
На выходе Check Output останутся три отдельных items, а не один сводный отчёт с count. Код не выполняет переименование повторно: он строит ожидаемые значения только для сравнения и возвращает результат штатного Rename Keys.
Check Input при этом должен по-прежнему содержать исходные названия полей. В проверенной версии Rename Keys создаёт выходную JSON-копию; для данного workflow отдельно сверено, что сохранённый результат Check Input не изменился.
Шаг 9. Проверьте конфликт и опечатку
В Sample Rows временно добавьте первому заказу поле id со значением "занято". Полный запуск должен остановиться в Check Input с input_fields_invalid: Rename Fields не должен получить такую запись. Затем удалите добавленное поле.
Не обходите Check Input ради эксперимента на рабочих данных. В отдельном диагностическом запуске редакция подтвердила: если передать одновременно order_id и уже занятое id непосредственно в Rename Keys, узел завершится успешно и новое значение id перезапишет старое. Это не защита от конфликтов.
Теперь временно замените Current Key Name у первой пары на orderid без подчёркивания. Rename Keys может завершиться успешно, пропустив отсутствующий ключ. Но Check Output должен остановиться с output_fields_mismatch. Верните order_id.
Замените sum_minor у второго заказа на строку "0": Check Input должен остановиться с sum_minor_invalid. Верните число 0. Эти проверки показывают три разные проблемы: конфликт имён, опечатку в настройках и неправильный тип входного значения.
Шаг 10. Восстановите пример и проверьте все записи
Верните исходный Sample Rows, четыре пары из шага 5 и пустые Additional Options. Выполните всю цепочку. На выходе Check Output должны быть ID 001, 002, 003 в этом порядке. Суммы — 150000, 0 и 49900, enabled — true, false, true; note — null, "Самовывоз" и пустая строка. Старых ключей быть не должно.
Переставьте строки в Sample Rows в обратном порядке и выполните ещё раз. На выходе должны быть 003, 002, 001: узел не сортирует записи. Оставьте одну запись — получите один item. Затем восстановите три исходных заказа.
Если источник возвращает ноль items, последующие узлы в проверенном workflow не выполняются. Статус success при этом не означает, что договор данных прошёл проверку. Для задачи, в которой отсутствие записей считается ошибкой, нужна отдельная обработка пустого источника; добавление искусственного пустого объекта не заменяет эту логику.
Если результат отличается
| Ошибка или симптом | Что проверить | Ожидается |
|---|---|---|
| input_fields_invalid | Лишнее, занятое или пропущенное поле | Ровно пять исходных полей |
| sum_minor_invalid | Тип и значение суммы | Безопасное целое, не строка |
| output_fields_mismatch | Опечатки и четыре пары Keys | Точный набор новых имён |
| output_value_or_order_mismatch | Порядок и значения после узла | Совпадение с Check Input |
| success без выходных items | Не пуст ли источник | Исходные записи действительно поступили |
Перед подключением API
Сверьте новые имена с документацией получателя. В примере customer — обычная строка; это не означает, что любое API примет имя клиента в таком поле. Если требуется вложенный объект или числовой идентификатор, это уже преобразование структуры или типа, не одно переименование.
Сначала сохраните результат как предпросмотр и проверьте его. Эта схема не отправляет заказы наружу, не удаляет поля в исходной базе и не решает конфликтующие значения автоматически. Изменять схему договора нужно вместе с проверками до и после Rename Keys.
Настроить поля через Edit Fields (Set)
Взять значения через Expressions
Остановить workflow при неверных данных
Что проверено редакцией
17 октября 2026 года workflow проверен на n8n 2.42.4 в отдельном Docker-экземпляре ручными запусками API. Все 27 тестов прошли: основной пример, одна и двадцать записей, обратный порядок, Unicode, нулевые суммы, false и null; дубли, неверные типы, пропущенные и лишние поля; занятые назначения id, customer, amount_minor и enabled; опечатка исходного ключа, неверное и повторяющееся новое имя, отсутствующая пара. Отдельно диагностически подтверждены перезапись занятого id штатным узлом без проверок и отсутствие последующих запусков при нуле items. Основной запуск использует точный скачиваемый workflow. Сверены значения, типы, порядок, отсутствие старых ключей и неизменность сохранённого результата Check Input. Настройки сверены с официальной документацией и кодом Rename Keys 1. Cloud, клики редактора, Regex, вложенные пути, binary, большие объёмы и реальные API не тестировались. Учебный контейнер остановлен, существующие workflows не менялись. Обложка — редакционная AI-иллюстрация отдельных полей, не снимок реального интерфейса.
Частые вопросы
Чем Rename Keys отличается от Edit Fields?
Здесь Rename Keys меняет имена уже существующих полей. Edit Fields удобен, когда нужно явно собрать выход, добавить или вычислить значения. Выбирайте узел по задаче, а не заменяйте проверку входных данных.
Сохранится ли строковый ID 001?
Да, в проверенном примере он остаётся строкой с ведущими нулями. Узел не восстанавливает нули, если источник уже превратил ID в число.
Что будет, если новое имя уже занято?
Штатный узел может перезаписать значение назначения. Поэтому Check Input в этой инструкции заранее отклоняет записи с новыми именами полей.
Почему отсутствующий ключ не вызвал ошибку?
В проверенной версии узел может пропустить отсутствующий исходный ключ. Для обнаружения опечаток и неполной структуры здесь есть отдельные проверки входа и выхода.
Можно переименовать вложенные поля и использовать Regex?
Узел поддерживает такие настройки, но эта инструкция проверена только для явных пар верхнего уровня без Regex. Вложенная структура и массовое переименование требуют отдельного договора и тестов.
