Ограничение частоты запросов (Rate Limit)

Ограничение частоты запросов (rate limit) — это ограничение, которое провайдер API накладывает на количество запросов, которые может сделать одно приложение, API-ключ или пользователь в течение заданного временного окна — например, «100 запросов в минуту» или «10 000 запросов в день», — предназначенное для защиты инфраструктуры провайдера от перегрузки, предотвращения злоупотреблений и (для платных API) обеспечения границ тарифных планов. Почему это особенно важно для no-code создателей: ограничения частоты запросов — одна из самых распространённых причин багов «моя автоматизация внезапно перестала работать», потому что workflow, который прекрасно работает при малом объёме (10 автоматизаций в день), может незаметно начать сбоить при масштабировании использования (10 000 автоматизаций в день внезапно упираются в лимит провайдера в 5000/день), и сбой часто выглядит как прерывистые, трудно диагностируемые ошибки, а не чёткое сообщение «вы превысили лимит», если только создатель специально не проверяет код статуса 429. Понимание ограничений частоты запросов также необходимо при проектировании автоматизаций, обрабатывающих массовые данные — циклический запуск автоматизации по 50 000 строк таблицы, каждая из которых вызывает отдельный API-запрос, почти всегда упрётся в ограничение частоты запросов на полпути, если только workflow не включает намеренное дросселирование или пакетную обработку. Как это работает: API обычно сообщают о статусе ограничения через заголовки ответа (например, `X-RateLimit-Limit: 100`, `X-RateLimit-Remaining: 23`, `X-RateLimit-Reset: 1719856800`), чтобы хорошо построенный клиент мог проактивно замедлиться до того, как упрётся в стену, и возвращают код статуса HTTP 429 «Too Many Requests», когда лимит действительно превышен, часто с заголовком `Retry-After`, указывающим, сколько нужно подождать перед повторной попыткой. Практический пример — обработка ограничения частоты запросов в сценарии Make, обогащающем 2000 лидов через сторонний API данных с лимитом 60 запросов/минуту: вместо того чтобы выстрелить всеми 2000 запросами как можно быстрее (что гарантированно вызовет ошибки 429 после первой минуты), создатель добавляет модуль «Sleep» после каждой партии из 50 записей — приостанавливая сценарий на вычисленную задержку перед продолжением — и оборачивает каждый вызов API в обработчик ошибок, который специально перехватывает ответ 429, читает заголовок `Retry-After`, ждёт указанное время, а затем повторяет тот же запрос вместо того, чтобы провалить весь запуск. Production-уровневые no-code автоматизации, работающие с большими объёмами вызовов API, всегда должны проектироваться с защитой от ограничений частоты запросов (пакетирование, дросселирование, повтор с экспоненциальной задержкой), а не реактивно (добавляя обработку только после того, как автоматизация начинает падать в продакшене). Некоторые API также применяют лимиты на всплески отдельно от устойчивых ограничений частоты (например, «10 запросов в секунду, до 1000 в день») — упирание в любой из потолков даёт один и тот же ответ 429, поэтому надёжная автоматизация проверяет заголовки ответа, а не полагается на единый фиксированный порог.