A validation may end without a verdict for reasons unrelated to the submitted data: Banxico is unresponsive, or the CEP is not published yet. The retry policy attempts it again automatically, without the client having to resend the request.
A retry consumes no additional quota: it belongs to the original validation.
Which outcomes are retried
| outcome | retried |
|---|---|
not_found | Yes. The CEP may be published later |
cep_unavailable | Yes. Banxico did not answer on the attempt |
error | Yes. Failure during processing |
valid | No. A verdict exists |
invalid | No. The submitted data does not form a valid query, and repeating it changes nothing |
The distinction is whether repeating the query can yield a different result. Malformed data is not fixed by insisting.
Caps
| cap | value |
|---|---|
| Retries per validation | 5 |
| Minimum interval between attempts | 5 minutes |
| Maximum interval | 24 hours |
| Maximum age of the validation | 7 days |
| Validations with a pending retry per account | 50 |
| Retries dispatched per day per account | 200 |
| Reactivations of a single validation | 3 |
The per-account caps guard against a backlog that would delay retries across all validations. Once the pending cap is reached, new validations are processed without automatic retry.
Configuration
The policy has two levels. The account default is read and changed through GET/PUT /v1/users/me/retry-policy, and applies to new validations. An individual validation is adjusted with PUT /v1/validations/{id}/retry-policy, which takes precedence over the account value.
State on the validation
Every validation exposes retry_state, even when no retries are active: in that case enabled is false and the policy fields are null. Rows coming from a bulk import always carry enabled: false.
Each transition of the cycle emits its webhook event — validation.retry.scheduled, validation.retry.resolved and validation.retry.exhausted — so tracking requires no polling. Delivery of those events is described in the webhooks architecture.