Подписки с metered usage и limit metered
Три роли метрик
| Механизм | Задача | Поведение |
|---|---|---|
| Limit metered | Квота | При превышении лимита новое событие отклоняется API |
| Charge metered | Счёт за объём | Накопленное значение × тариф (в т.ч. ступени) попадает в счёт цикла |
| Charge recurring | Регулярное начисление по правилу | Участвует в расчёте периода отдельно от простого счётчика (в т.ч. max per day) |
Пример: API с лимитом и переплатой
- План включает 100 000 запросов в месяц включено — задаётся metric limit на плане.
- Сверх лимита каждые 1000 запросов стоят 50 ₽ — вторая метрика типа charge metered со ступенчатым тарифом, или одна метрика с комбинированной политикой (зависит от того, как вы моделируете в продукте: часто лимит отдельно, overage отдельно).
Пример: только лимит без overage
Один тип limit metered: при достижении потолка ваше приложение получает ошибку на metricNewEvent и должно отвечать клиенту «лимит исчерпан».
Период сброса limit metered
По умолчанию usage для limit metered считается в рамках биллинг-периода подписки (limitResetPeriod = subscription_period).
Можно задать календарное окно на метрике:
limitResetPeriod | Поведение |
|---|---|
hour | Сброс каждый календарный час |
day | Сброс каждый календарный день |
week | Сброс каждую ISO-неделю |
calendar_month | Сброс каждый календарный месяц |
Timezone: user → merchant → UTC. В userMetric для UI доступны windowStart, windowEnd, windowResetsAt.
Несколько лимитов (час + день + месяц)
Для сценария «N в час, M в день, K в месяц» используйте limit group: несколько limit metered метрик с общим limitGroupCode, роли primary / member, один вызов metricNewEvent на primary.
Подробный рецепт с grants и докупкой пакетов: Токены и докупка пакетов.
Выбор схемы
После оплаты счёта
События метрик, вошедшие в расчёт оплаченного счёта, помечаются учтёнными, чтобы следующий цикл начинался с «чистого» накопления для биллинга.