The account's plan sets how many validations may run in a monthly cycle. Quota is consumed on admission of the operation, before processing, so consumption reflects accepted operations rather than those rejected by validation.

An automatic retry consumes no additional quota: it belongs to the validation that already spent it.

Consumption headers

Operations subject to quota report the state on every response, with no separate query needed:

headercontent
X-Quota-LimitCycle cap
X-Quota-UsedAccumulated consumption
X-Quota-RemainingRemaining allowance

These headers accompany both successful responses and the quota-exhausted one, unlike the rate limit headers, which appear only on rejection.

Exhausted quota

Once the cap is reached, operations subject to quota answer 429 with rate_limit_exceeded and a Retry-After header stating the seconds left until the next cycle.

The distinction from a rate limit is one of scale: a 429 from a rate limit clears by waiting seconds; one from an exhausted quota clears by changing plan or waiting for the next cycle. The Retry-After value tells them apart unambiguously.

The account receives a notice on reaching 80 % of its consumption and another on exhausting it, once per cycle.

Reading consumption

operationreturns
GET /v1/usage/summaryConsumption for the current cycle
GET /v1/usage/limitsApplicable caps and remaining allowance
GET /v1/usage/historyMonthly consumption over recent months
GET /v1/usage/breakdownCycle breakdown by operation type

History reflects the current plan cap in each period: past plan changes are not preserved, so an earlier month is shown against today's limit.