Если сценарий n8n нужно запускать из другой системы, обычно для этого используют узел Webhook, а публичный n8n API служит для управления: список сценариев, публикация и снятие с публикации, чтение, повтор и остановка запусков. Оба пути требуют ключей и ограничений, потому что внешний вызов открывает доступ к вашим автоматизациям. Права API шире, чем у вебхука, поэтому выдавать их приходится осторожнее.
Что открывает API
По документации n8n, публичный API позволяет делать программно то, что доступно в интерфейсе: работать со сценариями, запусками и другими объектами. Для запуска конкретного сценария событием снаружи используют Webhook, для управления экземпляром — API с ключом. В списке методов публичного API нет вызова «запустить сценарий с такими данными»: API повторяет или останавливает уже существующий запуск, а новый запуск с входными данными создаёт вебхук.
Публичный API доступен на самостоятельных установках всех редакций и в облаке на части планов, а во время пробного периода облака он закрыт. Точный перечень методов берите из справочника конечных точек: он генерируется из спецификации OpenAPI, поэтому актуальнее любой статьи. Начните со страницы n8n API в документации.
Эта статья о другом, чем сборка агента в интерфейсе, которую мы описывали в материале n8n агент: инструменты, память и контроль действий. Там сценарий строится внутри платформы, здесь речь о том, как внешняя система обращается к платформе и что ей позволено.
Бухгалтерская система должна сообщать n8n о новом счёте, а менеджеру нужна отдельная панель со статусом последних запусков. Для первой задачи подойдёт Webhook с проверкой заголовка, для второй — ключ API только на чтение запусков. Две задачи, два канала, два разных секрета: компрометация одного оставляет другой нетронутым.
Два канала различаются характером доступа. Вебхук отвечает на вопрос «запусти этот сценарий с такими данными», а ключ API отвечает на вопрос «покажи, измени, включи». Поэтому ключ API опаснее: он управляет самой платформой целиком, тогда как вебхук открывает один сценарий. Приём событий вебхуком мы подробно разобрали в статье про вебхуки n8n.
Ключ и права
Ключ создаётся в настройках экземпляра в разделе n8n API: вы задаёте название и срок действия, копируете значение и сразу прячете его в хранилище секретов: потерянный ключ проще перевыпустить, чем искать.
- Название по назначению: «интеграция CRM, чтение запусков» понятнее, чем «ключ 1», и при аудите сразу видно, кому он принадлежит.
- Короткий срок действия: ключ с истечением вынуждает регулярно обновлять доступ и сокращает ущерб от утечки.
- Области доступа (scopes): по документации, выбор областей при создании ключа доступен на корпоративном плане, на остальных ключ даёт полный доступ владельца, поэтому ограничения придётся делать иначе.
- Отдельный ключ на каждую систему: когда один из них скомпрометирован, остальные продолжают работать.
- Хранение вне кода: ключ лежит в менеджере секретов или переменных окружения сервера, а репозиторий и чаты остаются чистыми.
Если встроенных ограничений недостаточно, добавляйте внешние: доступ к API только из внутренней сети, правила межсетевого экрана и узкий список адресов. Размещение собственного экземпляра и сетевые настройки описаны в статье про локальную установку n8n.
Тестовый запрос
Отдельно решите, где живёт экземпляр. На собственном сервере вы управляете сетью и журналами сами, и API легко спрятать во внутреннюю сеть. В облаке сеть закрыта от вас, зато часть защитных слоёв обеспечивает провайдер. От этого выбора зависит набор мер, которые вы реально можете внедрить, поэтому сравнивайте варианты до выдачи первых ключей.
Прежде чем подключать внешнюю систему, проверьте доступ вручную. Проверка занимает несколько минут и показывает, какие права реально получил ключ.
- Возьмите тестовый ключ с коротким сроком и, если это возможно, с минимальными областями доступа.
- Отправьте запрос на получение списка сценариев, передав ключ в заголовке X-N8N-API-KEY, и убедитесь, что в ответе приходит список без лишних полей.
- Попробуйте действие, которое должно быть запрещено: например, запрос к объекту, на который у ключа нет прав. Ожидаемый результат — отказ.
- Проверьте реакцию на неверный ключ и на истёкший ключ: сервис должен отвечать отказом, вместо пустого списка.
- Запишите проверенные запросы и ответы в заметку: она станет основой регрессионной проверки после обновления платформы.
На самостоятельных установках есть встроенная страница интерактивной документации (Swagger UI), на которой запросы можно пробовать в браузере. Если она лишняя, её отключают переменной N8N_PUBLIC_API_SWAGGERUI_DISABLED, а сам публичный API, если снаружи он ни к чему, переменной N8N_PUBLIC_API_DISABLED. Для облачной версии такой страницы нет.
Аудит обращений
Журнал обращений отвечает на вопросы «кто, когда и что делал». Без него разбор инцидента превращается в догадки, а расследование утечки ключа начинается вслепую.
| Что записывать | Где взять | Зачем нужно |
|---|---|---|
| Какой ключ вызвал метод | Журнал сервера или шлюза перед n8n | Найти источник подозрительных запросов |
| Какие объекты читали или меняли | Журнал вызовов, история запусков | Понять масштаб затронутых сценариев |
| Время и адрес вызова | Журнал шлюза | Сопоставить с рабочими окнами интеграций |
| Отказы в доступе | Журнал шлюза и ответы сервиса | Заметить подбор ключей и ошибки настройки |
| Изменения сценариев | История изменений, контроль версий | Отличить плановое изменение от постороннего |
Отдельная история — изменение самих сценариев через API. Если интеграция умеет править сценарии, её ключ приравнивается к правам администратора процессов: она способна изменить логику, добавить новый узел или подменить адрес отправки. Такие права выдавайте единицам систем, а историю изменений храните в системе контроля версий, чтобы любую правку можно было откатить.
Просматривайте журнал по расписанию, заранее: еженедельный взгляд на отказы и необычные методы выявляет утечку раньше, чем её заметит бизнес. Договоритесь, кто отвечает за просмотр, и впишите это в регламент.
Какая система сейчас обращается к вашему n8n снаружи?
Граница с агентом
Хорошая привычка — раз в квартал проводить ревизию: перечитать список ключей, отозвать забытые, проверить сроки и сверить владельцев с актуальным составом команды. Ревизия короткая, а находит именно то, что копится годами: ключи уволившихся сотрудников, интеграции закрытых проектов и доступы, оформленные на время и оставшиеся навсегда.
Составьте список внешних систем, которые обращаются к n8n, и напротив каждой запишите способ входа, ключ, срок его действия и владельца. Любую строку без владельца считайте угрозой и закройте до следующей проверки.
Если API получает ИИ-агент, ограничения нужны жёстче: агент способен вызвать больше методов, чем предполагалось, и в неожиданной последовательности. Выдавайте ему отдельный ключ, отдельную среду и подтверждение людьми для действий, которые меняют сценарии. Стыковку агента со сценариями и разделение прав подробно описывает материал про n8n MCP и разделение прав.
Здоровье доступа показывает один счётчик: сколько ключей осталось без владельца или без срока действия. Цель — ноль. Один универсальный ключ «для всего» на год, которым пользуются несколько подрядчиков, через полгода превращается в загадку: вряд ли кто-то скажет, кто именно. Если ключей и интеграций накопилось больше, чем вы способны перечислить, начните с аудита: им занимается наш консалтинг по внедрению ИИ.