PartyFlow

Концепция: Rate Limits и Auto-disable#

Страница покрывает все три направления: входящие webhooks (вы → PartyFlow), исходящие (PartyFlow → вы), бот REST API.

Incoming webhooks (вы → PartyFlow)#

Лимиты на webhook#

Тариф msg/sec per webhook
Free 5
Pro 10
Enterprise 30

Лимит применяется per webhook, не per space. При превышении — HTTP 429 с Retry-After.

Retry стратегия (для отправителя)#

Status Ретраить? Как
4xx (кроме 429) Нет Исправить payload/токен/подпись.
429 Да Через Retry-After: <секунд>.
5xx Да Exponential backoff: 1s, 2s, 4s, 8s, max 5 попыток.

Auto-disable#

Webhook, давший 100 подряд ошибочных доставок (4xx или 5xx от endpoint'а), автоматически отключается. Все последующие запросы возвращают HTTP 410 Gone до тех пор, пока admin не включит webhook вручную в UI. Счётчик сбрасывается на первом успешном 2xx.

Как не словить auto-disable#

  • Тестируйте payload локально перед подключением в прод.
  • При смене secret — обновляйте его у отправителя сразу, не ждите 100 ошибок подряд.
  • Если endpoint возвращает 5xx → не ретраить бесконечно. Лучше остановиться и открыть алерт внутри себя, чем сжечь webhook auto-disable'ом.

Outgoing webhooks (PartyFlow → вы)#

Здесь роли обратные: PartyFlow — отправитель, вы — получатель. Rate-limit применяется к частоте отправки PartyFlow'ом, а не к вашей endpoint'е.

Лимиты на подписку#

Outgoing подписки делят лимиты по space-plan'у владельца. Точные числа публично не фиксируются, они настраиваются на уровне тарифа и могут меняться. Практически:

  • Free — компактный лимит, рассчитан на нечастые AI/LLM интеграции.
  • Pro — комфортный лимит для большинства ботов и аудит-приёмников.
  • Enterprise — максимум.

Когда отправка попадает в лимит, доставка не теряется: row в очереди получает failed со строкой rate_limited и откладывается на ~1 секунду. Attempts не инкрементируются — rate-limit'нутая доставка не расходует retry budget.

Retry стратегия (на стороне PartyFlow)#

PartyFlow ретраит неудачные доставки автоматически. Расписание — exponential backoff с конфигурируемыми Initial, Max, MaxAttempts. Текущие production-дефолты — Initial = 5s, Max = 1h, MaxAttempts = 8 (первая попытка + 7 ретраев), jitter ±20%:

Попытка Задержка перед ней (база) Кумулятивно
1 — T0
2 5s ±20% ~T0 + 5s
3 10s ±20% ~T0 + 15s
4 20s ±20% ~T0 + 35s
5 40s ±20% ~T0 + 1m 15s
6 80s ±20% ~T0 + 2m 35s
7 160s ±20% ~T0 + 5m 15s
8 320s ±20% ~T0 + 10m 35s
— После 8-й неудачной → dead-letter

Полное retry-window — ~10 минут 35 секунд от первой попытки до dead-letter (база, без jitter). Формула: delay = min(Initial · 2^(attempt-1), Max) ± Jitter. Расписание настраивается платформой и может быть скорректировано — ориентируйтесь на суммарный window, а не на число попыток.

Ретраибельно: 408, 429, 5xx, transport error (DNS/TCP/TLS). Не-ретраибельно (сразу dead-letter): все остальные 4xx — 400, 401, 403, 404, 422 и т.д. Это клиентская ошибка; ретрай не поможет.

Retry-After от получателя#

Если вы отвечаете 429 или 503 с заголовком Retry-After, PartyFlow уважает значение вместо exponential. Форматы (в порядке приоритета):

  1. Retry-After: 30 (delta-seconds, RFC 7231).
  2. Retry-After: Wed, 18 Apr 2026 14:35:00 GMT (HTTP-date).
  3. Body JSON {"retry_after": 30}.
  4. Body — просто число.

Допустимый диапазон — [1s, 1h]. Выход за границы → игнорируется, fallback на exponential.

Auto-disable подписки#

100 подряд dead-letter'ов → подписка автоматически отключается:

  • Подписка получает статус inactive.
  • Admin получает уведомление в UI.
  • Новые события больше не доставляются этой подписке.
  • Пропущенные события не буферизуются — после ручной активации они не догоняются.

Счётчик сбрасывается на первом 2xx. Чтобы не словить auto-disable на своей стороне: отвечайте 2xx быстро, деплойте receiver с graceful shutdown, не возвращайте 4xx на временные бизнес-ошибки.

Bots#

10 msg/sec на канал.

Превышение → HTTP 429 от Bot REST API с Retry-After.

Что дальше#