Публичный API n8n: что он умеет, чего не умеет и когда его лучше отключить

Публичный API n8n позволяет управлять workflow, executions, учётными данными, пользователями, тегами, переменными и другими ресурсами вашего экземпляра n8n через REST-вызовы, по базовому пути /api/v1, защищённому API-ключом в заголовке X-N8N-API-KEY. Он подходит для всего, что вы иначе делали бы вручную в интерфейсе, а вместо этого хотите автоматизировать из собственного скрипта, пайплайна или другой системы. Актуально на: август 2026 года.

Какие ресурсы конкретно охватывает API?

API охватывает, среди прочего, workflow, executions, credentials, users, журнал аудита, tags, source control, variables, data tables и projects, каждый как отдельную группу ресурсов со своими эндпоинтами. Это означает, что вы можете, например, создавать, активировать или деактивировать workflow через скрипт, выгружать данные выполнения для отчётности или централизованно управлять переменными, не переходя по интерфейсу. Полный список всех эндпоинтов вы найдёте в справочнике API n8n.

Где проходят границы публичного API?

Самое существенное практическое ограничение — пагинация: по умолчанию эндпоинт списка возвращает 100 записей за один вызов, максимум 250, поэтому на крупных экземплярах с большим числом workflow или executions приходится делать несколько вызовов с курсором. Для data tables добавляется ещё одно ограничение: по умолчанию общий объём хранилища ограничен 50 МБ на весь экземпляр. А тот, кто использует n8n Cloud в течение бесплатного пробного периода, вообще не имеет доступа к API — эта функция становится доступна только после перехода на платный тариф.

Как создать и управлять API-ключом?

API-ключ создаётся в разделе Settings, затем n8n API, через кнопку создания нового ключа, где вы указываете метку и, при желании, срок действия. На инстансах Enterprise ключ можно дополнительно ограничить определёнными ресурсами и действиями — так называемыми scopes, тогда как ключ на инстансе без Enterprise автоматически получает полный доступ ко всем ресурсам аккаунта. Подробности об аутентификации и доступных scopes указаны в документации по аутентификации API n8n.

Когда публичный API лучше отключить?

Публичный API стоит отключить, если вы фактически им активно не пользуетесь, ведь любой активный интерфейс — это дополнительная поверхность атаки, особенно на самостоятельно размещённом (self-hosted) инстансе без Enterprise-scopes, где скомпрометированный ключ означает полный доступ. Без лицензии Enterprise доступ невозможно ограничить детально, поэтому зачастую простейшим и самым безопасным решением становится полное отключение API, если от него не зависит ни одна внешняя система. Тем, кто эксплуатирует n8n в продакшене в собственном дата-центре, стоит в любом случае систематически заниматься такими вопросами усиления защиты, например в рамках консультирования по эксплуатации n8n.

Часто задаваемые вопросы о публичном API n8n

Можно ли через API также считывать credentials?

Ресурс Credential в API позволяет создавать и управлять учётными данными; сами сохранённые секретные значения n8n из соображений безопасности в открытом виде не возвращает. Для чисто административных задач, например для привязки credentials к workflow, на практике этого обычно достаточно.

Заменяет ли публичный API n8n CLI?

Нет, эти два инструмента скорее дополняют друг друга, чем заменяют: API рассчитан на удалённый программный доступ по HTTP, тогда как CLI предназначен для административных задач непосредственно на сервере, например для импорта и экспорта workflow во время деплоя. Какой инструмент подходит, зависит от конкретного случая применения.

Работает ли API в n8n Cloud так же, как в self-hosted версии?

В целом да, с той разницей, что в n8n Cloud API заблокирован во время бесплатного пробного периода и разблокируется только с переходом на платный тариф. У self-hosted инстансов такого ограничения нет, зато там вы несёте полную ответственность за защиту доступа.

Сколько API-ключей можно создать одновременно?

Вы можете создавать несколько API-ключей параллельно — это удобно, чтобы выдавать разным внешним системам собственный ключ с отдельной меткой и отдельным сроком действия, вместо того чтобы использовать один и тот же ключ повсюду. Это также облегчает целевой отзыв скомпрометированного или более не нужного ключа без нарушения работы других интеграций.