Сколько вебхуков помещается в тариф? Ответ зависит от того, какие данные они несут. Короткое уведомление об изменении статуса и большой JSON с подробностями заказа — это по одному запросу, но объём у них может различаться в десятки раз.
25 сентября 2026 года мы перевели Adal Cloud с кредитов на побайтовый учёт. Теперь квота расходуется по точному размеру принятых данных, без округления до блоков и без минимального списания за запрос. Повторные попытки доставки остаются бесплатными.
Мы хотим, чтобы расход было проще связать с работой интеграции: сколько данных она передаёт, столько и учитывается по описанным ниже правилам.
Запросы, кредиты или байты
Единицу тарификации можно выбрать по-разному. От этого зависит, что нужно знать команде, чтобы оценить свой расход.
| Подход | Что удобно | Что нужно учитывать |
|---|---|---|
| По количеству запросов | При стабильном потоке событий легко оценить нужный лимит | Маленький и большой запрос расходуют одинаковую единицу, если модель не вводит отдельные правила размера |
| В кредитах | Разные операции можно привести к общей единице | Нужно знать, сколько кредитов стоит каждая операция и как на списание влияет размер |
| По объёму с округлением до блоков | Размер данных влияет на расход | Каждый запрос может округляться вверх; небольшое увеличение на границе блока меняет списание скачком |
| Побайтово, как теперь в Adal Cloud | Расход напрямую связан с размером принятых данных | Для прогноза нужны и количество запросов, и их средний учитываемый размер |
Кредиты сами по себе не означают округление: всё зависит от правил конкретной системы. Но они добавляют промежуточную единицу между данными запроса и остатком тарифа. Мы убрали эту ступень из учёта Adal Cloud.
Разницу с блочной моделью удобно показать на условном примере. Если сервис считает каждый начатый блок по 64 KiB, запросы размером 65 536 и 65 537 байт займут один и два блока соответственно. В новой модели Adal Cloud разница между ними — ровно один байт. Это иллюстрация принципа округления, а не сравнение цен конкретных сервисов.
Что входит в размер запроса
Для входящего вебхука мы учитываем путь и query-параметры, сохраняемые пользовательские заголовки и тело запроса. Для Adal Outbound — полный URL получателя, пользовательские заголовки и тело после декодирования Base64.
Поэтому учитываемый размер немного шире привычного «размера JSON». Например, заголовок с подписью отправителя тоже содержит пользовательские данные и входит в расчёт. При этом Base64-обёртка исходящего тела не увеличивает его учитываемый объём: считаются декодированные байты.
Служебные данные Adal Cloud, транспортные накладные расходы и ответы получателя в этот размер не входят. Расчёт выполняется в байтах, поэтому для текста имеет значение размер его кодировки, а не число символов.
Расход фиксируется один раз при успешном сохранении нового входящего Request или принятии сообщения Adal Outbound. Это учёт принятого запроса: результат дальнейшей доставки не меняет уже учтённый объём.
Небольшие вебхуки расходуют небольшую часть квоты
Представим две интеграции. Обе передали по тысяче запросов, но в первой учитываемый размер каждого запроса — 1 KiB, а во второй — 100 KiB. Их расход составит около 0,98 MiB и 97,66 MiB соответственно.
Количество событий одинаковое, а объём данных различается в сто раз. Побайтовая модель сохраняет эту разницу. Короткое уведомление расходует квоту пропорционально своему размеру.
Для предварительной оценки достаточно простой формулы:
Объём за период ≈ количество новых запросов × средний учитываемый размер
Например, 500 MiB соответствуют 102 400 запросам по 5 KiB, если в эти 5 KiB уже входят все учитываемые части запроса и других расходов квоты нет. Это расчётный пример, а не фиксированное число вебхуков в тарифе: у реального потока размер меняется от события к событию.
Практическая польза — возможность оценивать потребность по собственным данным. Для небольших событий не нужно закладывать минимальный блок на каждый запрос, а увеличение размера отражается в расходе постепенно.
Retry не увеличивает расход
Получатель может временно не отвечать, вернуть ошибку или не успеть обработать запрос до тайм-аута. В такие моменты повторная попытка нужна для доставки уже принятого события.
В Adal Cloud автоматические retry и ручной retry существующей доставки не расходуют дополнительную квоту. Если запрос учтён как 5 KiB, несколько попыток доставить его не превратят этот расход в 15 или 25 KiB. Доставка того же входящего Request в несколько Destinations также не умножает его учитываемый размер.
Replay работает иначе: он создаёт новый Request из сохранённого исходного запроса. Поэтому Replay учитывается отдельно, по размеру оригинала. Это полезное различие при отладке: retry продолжает существующую доставку, Replay запускает обработку нового Request.
Новая отправка со стороны внешнего сервиса тоже может создать новый Request. Бесплатные retry относятся к повторной доставке внутри Adal Cloud, а не к любым запросам с одинаковым содержимым.
Общая квота для входящих и исходящих запросов
Новая квота общая для Серверов Adal Cloud и потоков владельца, включая Adal Outbound. Её не нужно заранее делить между отдельными Серверами или регионами.
На момент перехода тарифы включают следующий объём за период подписки:
| Тариф | Включённый объём |
|---|---|
| Free | 10 MiB |
| Developer | 500 MiB |
| Startup | 2 GiB |
Мы используем двоичные единицы: 1 KiB — 1 024 байта, 1 MiB — 1 048 576 байт, 1 GiB — 1 073 741 824 байта. Сам учёт остаётся точным до байта.
При продлении подписки предоставляется новая полная квота без накопления неиспользованного остатка. При переходе на более высокий тариф доступный остаток переносится один раз.
Квота отражает объём принятых данных за период. Удаление тела запроса по окончании срока хранения не возвращает уже использованный объём, как и ошибка доставки получателю.
Как работают ограничения
Максимальный учитываемый размер одного запроса для входящего потока и Adal Outbound — 10 MiB на любом тарифе. Этот технический предел действует отдельно от общего объёма подписки.
Квота мягкая: если региону известен положительный остаток, он может принять запрос целиком, даже когда размер запроса больше этого остатка. Данные о расходе синхронизируются между регионами не мгновенно, поэтому итоговый расход может выйти за квоту, в том числе при одновременных запросах.
После того как регион видит исчерпание квоты, новые входящие запросы получают HTTP 429, а новые сообщения Adal Outbound — HTTP 402. Мягкая граница позволяет принять целый запрос на остатке квоты, но не означает неограниченный приём после её исчерпания.
Что изменилось для действующих пользователей
Переход уже завершён. Аккаунты, подписки, Серверы, Destinations и данные в пределах срока хранения сохранены. Прежний расход кредитов не переводился в байты: действующие подписки начали новый учёт с нулевого расхода.
Теперь при оценке тарифа можно опираться на объём своих вебхуков и видеть расход в тех же единицах. Небольшие запросы занимают небольшую часть квоты, увеличение payload отражается без скачков округления, а retry остаётся инструментом восстановления доставки без дополнительного списания.
Откройте панель Adal Cloud и посмотрите доступный объём своей подписки. Сопоставьте его с количеством событий и средним размером запросов вашей интеграции — это и будет отправной точкой для выбора тарифа.