Compare two moments: before and after
tryVidimus can link two proofs of the same transaction, a "before" and an "after", so you can compare what each party captured. We do not compare the photos or judge the condition of the item: the proofs show what was captured, and weighing them is up to you.
1. Open the "after" from the "before"
Capture the "before" as usual and wait until its proof is sealed. Then create the second capture session with compare_to set to the id of that proof. The "before" must be sealed, with the same external_reference and the same party, and it must not itself be an "after". The answer repeats compare_to. If a rule is not met, no session is created: 422 compare_to_not_found, compare_to_not_sealed, compare_to_mismatch or compare_to_is_after.
$ curl -X POST https://api.tryvidimus.com/v1/capture-sessions \ -H "Authorization: Bearer $TRYVIDIMUS_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{"external_reference":"booking_4471","party":"provider","stage":"return","compare_to":"prf_01m4akapdbe8e8qq3er9r5qwyj"}'
2. Same shots, at least as many photos
The "after" uses a copy of the template of the "before": leave template_id out (naming another template fails with 422 compare_template_mismatch). Each shot photographed in the "before" becomes required, with at least as many photos. The capture page shows the photo of the "before" next to the camera, so the person takes the same one. Extra photos outside the template have no minimum.
3. Read the link on each proof
An "after" gives compare_to (the id of its "before"), a "before" gives compared_by (the id of its "after"). A proof is either a "before" or an "after", never both, and has at most one partner. To list the proofs still waiting for their "after", filter with linked=false; linked=true lists the pairs.
// GET /v1/proofs/prf_01m4akapdbe8ev5xgt0hkpcn14 (the "after")
{ "id": "prf_01m4akapdbe8ev5xgt0hkpcn14", "compare_to": "prf_01m4akapdbe8e8qq3er9r5qwyj", "compared_by": null, … }
// GET /v1/proofs/prf_01m4akapdbe8e8qq3er9r5qwyj (the "before")
{ "id": "prf_01m4akapdbe8e8qq3er9r5qwyj", "compare_to": null, "compared_by": "prf_01m4akapdbe8ev5xgt0hkpcn14", … }
// GET /v1/proofs?linked=false → the proofs still waiting for their "after"
4. When two links aim at the same "before"
Several links can aim at the same "before" as long as no "after" is finished. The first capture to be finished wins. The other is not saved: finishing it fails with 409 compare_to_already_used, no proof is created, no credit is used, and the person sees that their photos were not kept. The refusal appears in your logs. If the winning "after" fails for good, the "before" is free again.
5. Be told about a rejected capture
Subscribe your endpoint to capture_session.rejected: it is sent when a capture is rejected for this reason, once per session, even if the person tries again. Endpoints created before this event existed do not receive it until you add it to their events.
{
"event": "capture_session.rejected",
"session_id": "cps_01m4akapdbe8e8qq3er9r5qwyj",
"code": "compare_to_already_used",
"compare_to": "prf_01m4akapdbe8e8qq3er9r5qwyj",
"external_reference": "booking_4471",
"party": "provider",
"stage": "return",
"rejected_at": "2026-10-13T10:00:00.123Z"
}
6. Shots that need no photo
A shot of a template can allow the person to declare it instead of photographing it: allowed_skips lists nothing_to_report and/or not_applicable (empty by default: the shot cannot be skipped). A declared shot counts as done even when it is required. The declarations are kept with the proof, in skipped. They are statements of the person who captured, not measured by us, and they are not part of the signed manifest.
// In the template (POST /v1/capture-templates)
{ "id": "garden", "label": "Garden", "required": true, "allowed_skips": ["nothing_to_report", "not_applicable"] }
// On the proof, once the capture is finished
"skipped": [{ "step_id": "garden", "reason": "nothing_to_report" }]
From the command line
sessions create takes --compare-to, and proofs list takes --linked true or false. proofs get shows the partner and the declared shots.
$ tryvidimus sessions create --reference booking_4471 --party provider --stage return \ --compare-to prf_01m4akapdbe8e8qq3er9r5qwyj $ tryvidimus proofs list --linked false
A rejected capture is not an error on your side: read the webhook or the log, then create a new session if you need one.