Re-checks
Run the same approved plan again after a fix, within its limits, without a new approval.
- Outcome
- You can prove a fix on the live app without asking for approval again.
- Does not do
- A re-check runs the plan that was approved. To check something new, start a new verification.
A re-check runs every journey of an approved plan again, against the live app, after a fix has been deployed. It returns a new verification id and points back at the run it repeats; the earlier record is never touched. It runs all the journeys, not only the failed ones, because a run over a subset can only prove a repair, not the whole claim.
When no new approval is needed
- Within 24 hours of the person's approval of the plan.
- For at most 10 re-checks of that approval.
- On the same site: the same scheme and host. A different path on that site is allowed.
Outside those limits the API answers recheck_window_closed or recheck_limit_reached. Start a new verification and a person approves its plan again.
How to start one
This example called the earlier service, which is retired. Its commands and endpoints are no longer shown.
The response carries recheck_of, rechecks_left and recheck_window_ends_at, and GET /v1/verifications/{id} reports recheck_of on every run. A re-check needs a key with launch access, because it spends.
Each re-check is billed as one verification, the same as the first run.