Ограничения скорости

Каждый запрос к runtime REST API (/api/v1/runtime/*) и MCP-эндпоинту (POST /mcp) проходит через rate limiter со скользящим окном на каждый API key. Эта страница документирует лимиты, заголовки, которые вы получаете в ответ, и то, как правильно отступать.

Лимиты runtime по тарифам

Запросы считаются на каждый API key в скользящем окне 60 секунд (Redis ZSET). Потолок по тарифам:

Лимиты применяются на ключ, а не на рабочее пространство — два ключа в одном рабочем пространстве каждый получают полный бюджет тарифа. Квота на количество API key — отдельная и независимая от бюджета запросов: в рабочем пространстве free одновременно может быть только один активный ключ, но у этого ключа по-прежнему 60 запросов/мин.

Заголовки ограничения скорости

В каждом runtime-ответе — 2xx, 4xx и 5xx, как только аутентификация успешна — возвращаются три заголовка в нижнем регистре. В ответах 429 добавляется четвёртый.

Заголовки записываются в нижнем регистре буквально. Имена HTTP-заголовков регистронезависимые, но учитывайте, что некоторые конвейеры логирования сохраняют регистр — ожидайте x-ratelimit-*, а не X-RateLimit-*.

Что происходит при достижении лимита

Когда скользящее окно заполнено, сервер возвращает HTTP 429 с таким телом:

{
  "error": "Rate limit exceeded",
  "code": "RATE_LIMIT_EXCEEDED"
}

…плюс retry-after в секундах и обычная тройка x-ratelimit-* (remaining будет 0). Чтобы получить 429, всё ещё нужна аутентификация — запрос с неверным ключом получит 401 до того, как сработает limiter.

Стратегия клиента. Соблюдайте retry-after буквально. Не повторяйте раньше — окно скользящее, дёрганье его ничего не сбрасывает и только тратит квоту следующего слота. Если вы оркестрируете множество агентов, сериализуйте их или шардируйте так, чтобы пиковая параллельность оставалась ниже потолка вашего тарифа.

Пользовательский лимит запусков (отдельный слой)

Отдельный лимит на пользователя ограничивает исполнения пайплайнов значением 100 запусков в скользящий час, независимо от того, как они были инициированы (runtime API, MCP, веб-интерфейс, планировщик, вебхук). Он накладывается поверх лимита запросов по тарифу — вы можете быть в пределах HTTP-бюджета и всё ещё упираться здесь.

Запуски, отклонённые на этом слое, — это не HTTP 429 на runtime-поверхности; они падают внутри исполнителя с пользовательским сообщением («Превышен лимит запусков (100 в час)») и останавливают запуск до того, как выполнится хотя бы один шаг. Если вы оркестрируете большой бэкфилл, разбейте его так, чтобы оставаться ниже 100 запусков/час на пользователя, или запросите апгрейд тарифа.

Работает для REST и MCP

Да. Вызовы MCP-инструментов проходят через ту же проверку Bearer-аутентификации и скользящего окна, что и REST-вызовы, — run_action по MCP расходует один запрос окна 60 с, точно как POST /actions/:slug/run по REST. Смешивание транспортов на одном ключе делит один бюджет.

Паттерн клиента

Минимальный цикл отката, соблюдающий retry-after:

async function callRuntime(url: string, init: RequestInit): Promise<Response> {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch(url, init);
    if (res.status !== 429) return res;

    const retryAfter = Number(res.headers.get("retry-after") ?? "1");
    await new Promise((r) => setTimeout(r, retryAfter * 1000));
  }
  throw new Error("Rate-limit retries exhausted");
}

Два правила: не повторяйте быстрее, чем говорит retry-after, и ограничьте число попыток, чтобы стойкий 429 громко падал, а не вешал воркер навсегда.

Апгрейд

Если вы стабильно упираетесь в потолок, обновите тариф рабочего пространства в разделе Billing в веб-приложении Triggo. Старшие тарифы поднимают потолок запросов/мин и квоту активных ключей. Для устойчивой пропускной способности выше business обращайтесь в поддержку.

Смотрите также

• API Keys — области доступа, создание, ротация.
• Обзор интеграции с агентами — выбор поверхности REST или MCP.
• Лимиты workflow — таймауты, повторные попытки и ограничения исполнения в движке.