Узел Code в n8n — место для короткого скрипта на JavaScript или Python, который переделывает данные между двумя узлами сценария, когда готовые узлы вроде Edit Fields становятся громоздкими. Он подходит для нормализации полей, склейки значений и расчёта по списку строк; сетевые вызовы, чтение файлов и запись в бизнес-системы ему поручать нельзя. Если задачу решают два стандартных узла, код писать незачем: у скрипта возникает владелец, тест и расписание правок.
Задача узла
Code принимает элементы от предыдущего узла, выполняет ваш код и отдаёт новый список элементов. Один узел решает одну небольшую трансформацию с проверяемым входом и выходом.
Условный пример: форма на сайте присылает заявки пачкой. В одной строке телефон начинается с «+7», в другой с «8» и скобками, дата лежит строкой вида «05.10.2026», а CRM принимает один формат. Замену пары символов выполнят стандартные узлы. Когда правил набирается десяток и у них есть исключения, один узел Code читается проще цепочки из шести узлов с условиями.
Откуда данные приходят и как узлы передают их друг другу, описано в материале про выбор узлов сценария; здесь речь только о Code. Целиком процесс с триггером и обработкой ошибок раскладывает статья про рабочие сценарии n8n.
Отдельный вопрос — кто читает код. Если заявки обрабатывает операционист, а сценарий правит один разработчик, скрипт превращается в зону, куда заглядывает только автор. Поэтому в описании узла запишите словами правило, которое он применяет: «телефон приводим к виду +7 и десяти цифр, пустой остаётся пустым». Правило в одной строке помогает проверяющему сверить поведение без чтения кода и заметить расхождение между описанием и скриптом.
Хороший кандидат для скрипта обладает тремя признаками: вход известен заранее, результат сверяется глазами на десяти строках, ошибка видна сразу. Приведение формата, подсчёт итогов, фильтр по условию подходят. Решение позвонить клиенту или сменить статус сделки лежит за пределами скрипта: его принимает система правил на сервере или человек, а скрипт готовит для них аккуратные данные.
Режимы и данные
У узла два режима. По умолчанию код выполняется один раз для всех элементов пачки, второй режим запускает его для каждого элемента отдельно. Выбор определяет, что код видит и что обязан вернуть, поэтому ошибки чаще всего начинаются именно здесь.
| Режим | Когда выбирать | Что вернуть | Типичный промах |
|---|---|---|---|
| Один раз для всех элементов | Группировка, сортировка, итоги по пачке, удаление повторов | Массив элементов, у каждого поле json | Вернуть один объект вместо массива |
| Один раз для каждого элемента | Очистка и форматирование полей строки | Один элемент на каждый вызов | Ждать, что код видит соседние строки |
Формат возврата — вторая по частоте причина ошибок. Узел ждёт список элементов, где значения лежат внутри ключа json; голая строка или объект без обёртки приведут к пустому результату или ошибке на следующем узле. Проверяйте вывод во вкладках Table и JSON: в первой видно, сколько строк вышло, во второй точная структура. Если скрипт пропускает все строки без отбора, число строк на выходе обязано совпасть с входом, а расхождение сразу показывает потерянные записи.
Язык выбирайте по команде, которая будет читать код через полгода. JavaScript в узле основной вариант: он поддерживает промисы и вывод отладки через console.log. Python в документации представлен нативной реализацией на task runners: поля читаются через квадратные скобки, а из встроенных переменных доступны только _items и _item. Прежний вариант на Pyodide из n8n 2.0 удалён, поэтому старые сценарии с ним перед обновлением проверьте отдельно: переход на нативный Python документация называет несовместимым изменением.
Данные внутри узла доступны через встроенные переменные: в JavaScript они начинаются со знака доллара, в Python с подчёркивания. Перечень методов лежит в справке по узлу Code; держите её открытой при первом скрипте, угадывать имена методов дороже.
Пишем и проверяем
- Выполните предыдущий узел и закрепите его вывод. Закрепление замораживает данные на время разработки, а рабочий запуск игнорирует их и просит свежие.
- Напишите минимальный код: прочитайте элементы, измените одно поле, верните массив объектов с ключом json. Лишние правила добавляйте по одному.
- Нажмите Execute step и сверьте вывод с ручным расчётом на десяти строках. В десятку включите пустое поле, слишком длинную строку и значение в неожиданном формате.
- Для отладки в JavaScript используйте console.log, но уберите вывод, когда скрипт принят: в журнале браузера легко оставить чужие персональные данные.
Тестовые строки берите вымышленные. Закреплённые данные хранятся вместе со сценарием и способны уехать в его экспорт, поэтому перед передачей файла коллегам проверьте, что настоящих клиентов там нет. Если скрипт падает на пустом значении, правка занимает одну строку, а в рабочем запуске та же пустота остановила бы всю пачку.
Какую пачку данных вы приводите к одному формату вручную?
Границы исполнения
Скрипт работает в изолированной среде и многое оттуда недоступно намеренно. Документация перечисляет ограничения прямо, и каждое из них подсказывает, какой стандартный узел надо поставить рядом.
- Файловой системы у узла нет: чтение и запись файлов выполняют узлы Read/Write File.
- Сетевых запросов внутри кода нет: за HTTP отвечает узел HTTP Request, там же настраиваются авторизация и повторы.
- В n8n Cloud для JavaScript открыты только модули crypto и moment, в Python импорт любых библиотек запрещён.
- На своём сервере сторонние модули разрешает администратор через переменные NODE_FUNCTION_ALLOW_BUILTIN и NODE_FUNCTION_ALLOW_EXTERNAL; по умолчанию импорт модулей отключён. Для Python нужные библиотеки добавляют в образ n8nio/runners и разрешают явно.
Для самостоятельного сервера документация рекомендует запускать код через task runners — внешние процессы, отделённые от основного. Решение принимает тот, кто отвечает за установку; детали размещения разобраны в материале про локальную установку n8n. Каждый открытый модуль расширяет поверхность атаки, поэтому разрешайте поимённо и записывайте причину.
Скрипт из чужого сценария — это чужой код на вашем сервере. Прочитайте его целиком до включения, найдите в нём адреса, переменные окружения и запись куда-либо, и запустите на вымышленных данных в отдельном тестовом сценарии.
Приёмка кода
Принятый скрипт сопровождает короткая карточка: что он принимает, что возвращает, кто отвечает, на каких строках проверен. Карточка живёт в описании сценария или рядом с ним. Когда через месяц изменится формат формы, владелец откроет карточку, найдёт нужный набор строк и повторит тест; разбирать код по памяти ни к чему.
Полезная проверка перед включением: подайте на вход пустую пачку и пачку из одной строки. Первая показывает, как скрипт ведёт себя без данных, вторая ловит ошибки в режиме для каждого элемента. Падение на любом из этих случаев означает, что сценарию нужен узел проверки до Code.
Что делать, когда скрипт разросся. Если он перевалил за экран и в нём появились ветки под разных клиентов, разделите его на два узла Code с одной задачей у каждого либо вынесите логику в отдельный сервис и вызывайте его через HTTP Request. Так проверка идёт по частям, а сбой в одном правиле находится без перечитывания целого файла.
Возьмите одну ручную операцию над таблицей, которую сотрудник повторяет каждую неделю. Опишите вход и выход на десяти строках, напишите скрипт и сверьте итог с ручным результатом. Когда нужна сборка процесса целиком с правами и журналом, посмотрите, как мы автоматизируем бизнес-процессы.