Как сделать ИИ-агента для работы с API без кода

Что получится в результате

Соберем ИИ-агента, который помогает подключать API без программирования: читает документацию, готовит HTTP-запросы, проверяет ответы и собирает workflow в n8n.

Первая рабочая версия будет делать так:

1. вы описываете API в таблице `api_catalog`;
2. n8n хранит ключи в credentials, а не в таблице;
3. агент получает задачу: что нужно прочитать или создать через API;
4. LLM готовит черновик HTTP Request: method, URL, headers, query, body;
5. workflow проверяет, что метод безопасный;
6. тестовый запрос выполняется на sandbox endpoint или read-only endpoint;
7. ответ валидируется по JSON schema;
8. результат попадает в `api_runs`;
9. опасные действия вроде POST/PUT/DELETE требуют approval;
10. approved-запрос можно использовать в боевом workflow.

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

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets.
• API с документацией и тестовым endpoint.
• Ключ API, OAuth token или Basic Auth.
• Понимание, какие методы read-only, а какие меняют данные.
• API-ключ LLM-провайдера.
• 60-90 минут на первый рабочий workflow.

Шаг 1. Выберите простой API для теста

Не начинайте с платежей, бухгалтерии или удаления данных.

Для первого прототипа возьмите read-only сценарий:

получить список сделок, задач, товаров, платежей или статей из API

Подходящие методы:

• `GET /items`;
• `GET /deals`;
• `GET /tasks`;
• `GET /payments`;
• `GET /articles`.

Не берите в первый тест:

• `DELETE`;
• массовый `POST`;
• изменение цен;
• оплату;
• отправку сообщений клиентам.

Проверка: выбранный endpoint можно безопасно вызвать несколько раз.

Шаг 2. Создайте таблицу проекта

Создайте Google Sheet:

No-code API AI agent

Добавьте листы:

api_catalog
endpoint_map
request_queue
api_runs
approval_queue
error_log
settings
test_cases

Проверка: у n8n есть доступ на чтение и запись.

Шаг 3. Опишите API в api_catalog

В листе `api_catalog` сделайте колонки:

api_id
api_name
base_url
auth_type
docs_url
environment
owner
enabled

Пример:

crm-demo
CRM Demo API
https://api.example.com/v1
bearer
https://api.example.com/docs
sandbox
Иван
yes

Важно: не добавляйте сюда токен.

Проверка: в таблице есть base URL и тип авторизации, но нет секретов.

Шаг 4. Создайте credentials в n8n

В n8n откройте `Credentials`.

Создайте credential для API:

Name: CRM Demo API Bearer
Type: HTTP Header Auth или Bearer Auth
Header Name: Authorization
Value: Bearer YOUR_TOKEN

Если API использует Basic Auth:

Type: Basic Auth
User: USERNAME
Password: PASSWORD

Проверка: ключ хранится в credentials n8n, а не в Google Sheets, prompt или Code node.

Шаг 5. Опишите endpoints

В листе `endpoint_map` сделайте колонки:

endpoint_id
api_id
name
method
path
purpose
changes_data
requires_approval
allowed
sample_query_json
sample_body_json

Пример read-only endpoint:

crm-deals-list
crm-demo
Список сделок
GET
/deals
Получить список сделок
no
no
yes
{"limit": 50}
{}

Пример опасного endpoint:

crm-task-create
crm-demo
Создать задачу
POST
/tasks
Создать задачу менеджеру
yes
yes
yes
{}
{"title": "Проверить сделку", "assignee_id": "123"}

Проверка: у каждого endpoint явно указано, меняет ли он данные.

Шаг 6. Создайте очередь запросов

В листе `request_queue` сделайте колонки:

request_id
api_id
endpoint_id
user_goal
input_json
status
created_by
created_at
processed_at
error

Пример:

REQ-1001
crm-demo
crm-deals-list
Получить 50 последних открытых сделок
{"status": "open", "limit": 50}
new
Иван
2026-05-22

Проверка: пользователь описывает цель и входные данные, а не редактирует HTTP node руками.

Шаг 7. Создайте журнал запусков

В листе `api_runs` сделайте колонки:

run_id
request_id
api_id
endpoint_id
method
url
query_json
body_json
http_status
response_preview
validation_status
result_status
created_at

Проверка: каждый API-запрос можно повторить и разобрать.

Шаг 8. Создайте очередь approval

В листе `approval_queue` сделайте колонки:

approval_id
request_id
endpoint_id
method
url
body_json
risk_reason
review_status
approved_by
approved_at
executed_at
error

Статусы:

• `draft`;
• `approved`;
• `rejected`;
• `done`;
• `error`.

Проверка: POST/PUT/PATCH/DELETE не выполняются сразу.

Шаг 9. Создайте workflow подготовки запроса

Назовите workflow:

No-code API request builder

Добавьте узлы:

1. `Manual Trigger` или `Schedule Trigger`;
2. `Google Sheets` - чтение `settings`;
3. `Google Sheets` - чтение `api_catalog`;
4. `Google Sheets` - чтение `endpoint_map`;
5. `Google Sheets` - чтение `request_queue`;
6. `Filter` по `status = new`;
7. `LLM` - сборка запроса;
8. `Code` - проверка JSON;
9. `Code` - safety check;
10. `HTTP Request` - только для safe GET;
11. `Google Sheets` - запись `api_runs`;
12. `Google Sheets` - запись `approval_queue`, если запрос рискованный;
13. `Google Sheets` - запись `error_log`.

Проверка: workflow создан и пока обрабатывает только тестовые запросы.

Шаг 10. Подготовьте prompt для сборки запроса

System prompt:

Ты помощник по настройке HTTP API в no-code workflow.
Твоя задача - собрать HTTP request по описанному endpoint.
Не придумывай endpoint, если его нет в endpoint_map.
Не добавляй API keys, токены и секреты в headers.
Не используй DELETE.
Верни только валидный JSON.

User prompt:

API:
{{api_catalog_row}}

Endpoint:
{{endpoint_map_row}}

Цель пользователя:
{{user_goal}}

Входные данные:
{{input_json}}

Верни JSON:
{
  "method": "GET|POST|PUT|PATCH|DELETE",
  "url_path": "/path",
  "query": {},
  "headers": {},
  "body": {},
  "expected_response": "что должно вернуться",
  "risk_level": "low|medium|high|critical",
  "needs_approval": true,
  "reason": "почему так"
}

Проверка: ответ не содержит токенов и не выходит за endpoint_map.

Шаг 11. Проверьте JSON

Добавьте узел `Code`.

Правила:

• JSON парсится;
• `method` совпадает с endpoint_map;
• `url_path` совпадает с endpoint_map;
• `headers` не содержит `Authorization`;
• `body` пустой для GET;
• `DELETE` всегда блокируется;
• если `changes_data = yes`, `needs_approval = true`.

Если проверка не прошла, запишите в `error_log`.

Проверка: LLM не может самовольно поменять GET на POST или добавить секрет.

Шаг 12. Соберите URL и query

В `Code` соберите:

const baseUrl = String($json.base_url || '').replace(/\/$/, '');
const path = String($json.url_path || '');
const url = `${baseUrl}${path}`;

return [{
  ...$json,
  final_url: url
}];

Query parameters передавайте через настройки HTTP Request node, а не вручную склеенной строкой, если n8n это позволяет.

Проверка: URL не содержит двойных `//` и не уходит на другой домен.

Шаг 13. Выполните безопасный GET-запрос

В `HTTP Request` настройте:

Method: {{$json.method}}
URL: {{$json.final_url}}
Authentication: credential из n8n
Send Query Parameters: true
Response Format: JSON
Timeout: 30 seconds

Выполняйте автоматически только если:

method = GET
changes_data = no
allowed = yes

Проверка: read-only запрос возвращает HTTP 200 и JSON.

Шаг 14. Обработайте HTTP-статусы

Добавьте узел `Code` после HTTP Request.

Минимальная логика:

2xx -> success
400 -> bad_request
401 -> auth_error
403 -> permission_error
404 -> not_found
429 -> rate_limited
5xx -> server_error

Не считайте любой ответ “успехом”.

Проверка: 401 не записывается как успешная интеграция.

Шаг 15. Валидируйте ответ

Для первой версии проверьте минимум:

• ответ JSON;
• есть ожидаемые поля;
• массив не слишком большой;
• нет поля `error`;
• нет пустого ответа, если ожидались данные.

Пример:

const data = $json.response;
let validation_status = 'ok';
let reason = '';

if (!data) {
  validation_status = 'fail';
  reason = 'empty response';
}

return [{ ...$json, validation_status, validation_reason: reason }];

Проверка: workflow отличает “API ответил” от “данные пригодны”.

Шаг 16. Запишите результат в api_runs

В `api_runs` добавьте строку:

run_id
request_id
api_id
endpoint_id
method
url
query_json
body_json
http_status
response_preview
validation_status
result_status
created_at

`response_preview` ограничьте 1000-2000 символами.

Проверка: в таблице видно, что именно вызвали и что вернулось.

Шаг 17. Отправьте рискованные запросы в approval

Если метод:

• `POST`;
• `PUT`;
• `PATCH`;
• `DELETE`;

или `changes_data = yes`, не вызывайте API сразу.

Добавьте строку в `approval_queue`:

review_status: draft
risk_reason: метод меняет данные

Проверка: создание задачи или изменение записи не происходит без человека.

Шаг 18. Проверьте approval человеком

Ответственный открывает `approval_queue`.

Проверяет:

• верный endpoint;
• верный method;
• нет лишних полей в body;
• действие не массовое;
• действие не удаляет данные;
• есть тестовая среда или sandbox;
• можно ли откатить действие.

После проверки ставит:

review_status: approved
approved_by: имя
approved_at: дата

Или:

review_status: rejected
error: причина

Проверка: approved означает, что человек понимает, какой API-запрос уйдет.

Шаг 19. Создайте workflow выполнения approved-запросов

Назовите workflow:

No-code API execute approved

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `approval_queue`;
3. `Filter` по `review_status = approved`;
4. `Code` - финальная safety проверка;
5. `HTTP Request` - выполнение;
6. `Google Sheets` - обновление approval_queue;
7. `Google Sheets` - запись api_runs;
8. `Google Sheets` - запись error_log.

Проверка: workflow не выполняет `draft` и `rejected`.

Шаг 20. Добавьте финальную safety проверку

Перед HTTP Request:

const forbidden = ['DELETE'];
const method = String($json.method || '').toUpperCase();

if (forbidden.includes(method)) {
  throw new Error(`Blocked method: ${method}`);
}

if ($json.review_status !== 'approved') {
  throw new Error('Request is not approved');
}

const body = JSON.stringify($json.body_json || {});
if (body.includes('api_key') || body.includes('password') || body.includes('secret')) {
  throw new Error('Body contains secret-like fields');
}

return [$json];

Проверка: даже ошибочная строка в таблице не выполнит DELETE.

Шаг 21. Сделайте шаблон для нового API

Чтобы подключать следующий API быстрее, используйте чеклист:

1. прочитать docs;
2. создать credential в n8n;
3. добавить API в `api_catalog`;
4. добавить endpoint в `endpoint_map`;
5. отметить `changes_data`;
6. сделать тестовый GET;
7. записать expected response;
8. добавить test_case;
9. только потом подключать POST/PUT.

Проверка: новый API подключается по одинаковой схеме.

Шаг 22. Добавьте error_log

В листе `error_log` сделайте колонки:

error_id
request_id
endpoint_id
step
http_status
error_type
error_text
payload_preview
created_at
resolved_at

Записывайте ошибки:

• invalid LLM JSON;
• auth error;
• permission error;
• rate limit;
• timeout;
• schema validation failed;
• unsafe method.

Проверка: ошибка интеграции не теряется в истории workflow.

Шаг 23. Добавьте retries и rate limit

Для 429 и временных 5xx:

повторить 2-3 раза с паузой
если не помогло, записать error

Не повторяйте автоматически POST, если не уверены, что API поддерживает idempotency key.

Для POST добавьте:

idempotency_key = request_id

если API это поддерживает.

Проверка: workflow не создает дубли из-за повторной отправки.

Шаг 24. Сделайте regression test

В листе `test_cases` сделайте колонки:

case_id
endpoint_id
input_json
expected_method
expected_needs_approval
expected_status
enabled

Добавьте тесты:

• безопасный GET;
• POST требует approval;
• DELETE блокируется;
• endpoint не найден;
• body содержит secret;
• неверный auth_type;
• пустой ответ;
• 401;
• 429;
• успешный approved POST в sandbox.

Создайте workflow:

No-code API regression test

Он проверяет prompt, safety checks и маршрутизацию без боевых запросов.

Проверка: изменение prompt не открывает опасные методы.

Шаг 25. Подготовьте документацию для команды

В отдельном листе или документе опишите:

• какие API подключены;
• где хранятся credentials;
• какие endpoints разрешены;
• какие методы требуют approval;
• кто владелец каждого API;
• где смотреть ошибки;
• как откатить действие.

Проверка: workflow может поддерживать не только тот, кто его собрал.

Шаг 26. Перенесите в боевой процесс

Перед боевым запуском проверьте:

• API работает в sandbox;
• GET-запросы успешны;
• POST/PUT требуют approval;
• DELETE заблокирован;
• credentials не лежат в таблицах;
• error_log заполняется;
• есть timeout;
• есть обработка 401/403/429/5xx;
• regression test проходит;
• владелец API подтвердил сценарий.

Проверка: боевой workflow начинается с одного безопасного endpoint, а не со всех методов сразу.

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• API описан в `api_catalog`;
• endpoint описан в `endpoint_map`;
• ключ хранится в n8n credentials;
• request_queue принимает пользовательскую цель;
• LLM собирает JSON запроса;
• safety check блокирует опасные методы;
• safe GET выполняется;
• ответ валидируется;
• POST/PUT/PATCH уходят в approval;
• все ошибки пишутся в `error_log`;
• regression test проверяет базовую безопасность.

Что нельзя автоматизировать в первой версии

• DELETE-запросы;
• массовые изменения данных;
• платежи и возвраты;
• изменение цен;
• отправку сообщений клиентам;
• создание пользователей и выдачу прав;
• хранение API keys в таблицах или prompt;
• выполнение POST без approval;
• работу с API без документации.

Частые вопросы

Можно ли подключить API вообще без программиста?

Да, если API простой, есть документация, ключи и понятные примеры. Но для платежей, персональных данных, бухгалтерии и массовых изменений нужен технический специалист.

Где хранить API-ключ?

В credentials n8n или секретах платформы автоматизации. Не храните ключ в Google Sheets, prompt, URL, Code node или истории чата.

Почему GET можно выполнять сразу, а POST нет?

GET обычно читает данные, а POST/PUT/PATCH меняют состояние системы. Поэтому read-only запросы можно тестировать безопаснее, а изменяющие запросы должны проходить approval.

Что делать, если API возвращает 401?

Проверьте credential, срок жизни токена, тип авторизации, заголовок Authorization и права приложения. Не пытайтесь чинить 401 через LLM, передавая ему секреты.

Какой минимум нужен для запуска?

`api_catalog`, `endpoint_map`, `request_queue`, `api_runs`, `approval_queue`, `error_log`, n8n HTTP Request, credentials, safety checks и один успешный read-only GET.