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:
| header | content |
|---|---|
X-Quota-Limit | Cycle cap |
X-Quota-Used | Accumulated consumption |
X-Quota-Remaining | Remaining 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
| operation | returns |
|---|---|
GET /v1/usage/summary | Consumption for the current cycle |
GET /v1/usage/limits | Applicable caps and remaining allowance |
GET /v1/usage/history | Monthly consumption over recent months |
GET /v1/usage/breakdown | Cycle 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.