429 Too Many Requests со стандартным ответом об ошибке.
Лимиты Messaging API
rps означает количество запросов в секунду (rps). Отправитель — это рабочий номер телефона WhatsApp.
Для большинства эндпоинтов действует ограничение 200 rps на аккаунт. Для эндпоинтов отправки WhatsApp действуют лимиты на отправителя, указанные выше. Ознакомьтесь с документацией Meta по пропускной способности касательно автоматических повышений.
Асинхронная и прямая отправка сообщений WhatsApp
YCloud учитывает лимиты для двух эндпоинтов отправки WhatsApp раздельно. Эндпоинт отправки через очередь/v2/whatsapp/messages принимает до 200 rps на отправителя, в то время как YCloud передает сообщения из очереди в Meta со скоростью 60 rps. Помещение сообщения в очередь не означает, что Meta приняла или доставила его.
Избегайте одновременной отправки с высокой частотой через оба эндпоинта от одного и того же отправителя. При отправке через очередь и прямой отправке используется один и тот же рабочий номер телефона WhatsApp, поэтому их суммарный трафик может достигнуть лимита Meta и привести к ошибкам.
Лимиты Management API
Большинство API без отдельно задокументированных правил относятся к Management API. Эти эндпоинты делят общую квоту аккаунта: 200 запросов в секунду и 10 000 запросов в час. Применяются оба лимита: невозможно непрерывно отправлять 200 rps в течение всего часа. Запросы к одному эндпоинту управления расходуют квоту, доступную для остальных. Общие правила распространяются на:/v2/balance/v2/webhookEndpoints/*/v2/whatsapp/businessAccounts/*/v2/whatsapp/phoneNumbers/*/v2/whatsapp/templates/*/v2/whatsapp/messages/{id}- Другие API без отдельно задокументированных правил
Чтение заголовков с информацией об ограничениях частоты
YCloud включает сведения об ограничениях частоты запросов в большинство ответов API. Считывайте заголовки при их наличии, а не исходите из предположения, что все эндпоинты имеют одинаковую квоту.Заголовки
RateLimit-* находятся на этапе бета-тестирования и могут измениться. Описанный формат
заголовков YCloud следует спецификации IETF draft-06 для rate limit. Рассматривайте параметры
правил как информационные и настраивайте клиент так, чтобы он был устойчив
к появлению дополнительных параметров.Пример: исчерпана общая почасовая квота
Обработка ответа 429
- Приостановите запросы, использующие исчерпанную квоту аккаунта или отправителя.
- Учитывайте заголовок
Retry-After, если он присутствует. Не повторяйте попытку до истечения указанного времени задержки. - Снизьте уровень параллелизма и добавьте экспоненциальную задержку (exponential backoff) со случайным разбросом (jitter).
- Ограничивайте количество повторных попыток числом попыток или таймаутом вашего приложения.
- Логируйте эндпоинт, HTTP-метод, ошибку
code,requestIdи время запроса. Исключайте ключи API и персональные данные.
Retry-After, отложите последующие запросы; не отправляйте повторно уже выполненный запрос. Отслеживайте RateLimit-Remaining и RateLimit-Reset, чтобы снизить частоту отправки до исчерпания квоты.
Повторная отправка с задержкой и случайным разбросом (backoff and jitter)
В этом примере на JavaScript значениеRetry-After рассматривается как минимальное время ожидания. Максимальный предел задержки ограничивает разброс приложения; он не сокращает время ожидания, запрошенное сервером. Количество попыток и настройки задержки определяются логикой приложения, а не лимитами API.
Управление параллелизмом и повторными попытками
Используйте очередь ограниченного размера и общий лимит воркеров. Избегайте независимых циклов повторных попыток, каждый из которых предполагает доступность полной квоты аккаунта или отправителя. Восстанавливайте объем трафика постепенно после окончания ограничения. Повторный запросPOST может создать еще один ресурс или отправить еще одно сообщение. Сначала ознакомьтесь с рекомендациями по повторным попыткам для конечной точки и сохраненным результатом. Где это поддерживается, сохраняйте постоянный externalId, но не рассматривайте его как универсальный ключ идемпотентности. Сохраняйте ID ответа YCloud и устраняйте неоднозначные результаты перед повторной отправкой.
Отслеживайте объем запросов, ответы 429, задержку, количество повторных попыток и время нахождения в очереди в разрезе конечных точек и отправителей. См. Рекомендации по работе с WhatsApp Messages API касательно постановки в очередь, сверки и предотвращения дублирования.
