Verify again

POST /api/kyc/verifications/:id/rerun

Asks the applicant to redo a finished verification: the same workflow, the same person reference, and a link to send them. Use it when a document has expired, a check failed on something fixable, or your own policy asks for periodic re-verification. This is the API twin of the dashboard's "Verify again" button, and the same operation as sending a verification back with Decide a verification. All of them run one core.

The verification keeps its id. When the applicant resubmits, what they send becomes the next attempt of this same verification, not a second verification. What the earlier attempt found is kept rather than overwritten: it is listed under attempts on the result and shown on the verification's timeline in your dashboard. You hold one id per applicant per check, and your webhook handler keeps updating the record it already has.

Calling it sets the verification's status to awaiting_resubmission and sends verification.status_updated. Any link sent earlier for the same verification stops working, so the applicant can only ever use the latest one.

Authentication: Authorization: Bearer sk_… (secret key required). The response contains a live verification credential. A publishable key receives 403 secret_key_required. Content type: application/json. Production note: sk_live_ keys require an approved business.

Redo only what failed

By default the applicant walks the whole flow again. Pass steps to narrow the redo to specific sections instead: a selfie that did not match does not require the applicant to re-photograph a perfectly good document.

{ "steps": ["liveness"], "message": "Your selfie was too dark to match. Please retake it in good light." }

The applicant then walks only the ticked steps, with your message shown when they open the link. Everything they are not asked to redo is kept from the earlier attempt. Valid step names:

An unknown step name is refused with 400 invalid_steps rather than ignored. A silently dropped typo would turn a targeted redo into a full one, which is the one failure you could not see happening.

Email the link

Pass email and we send the link to the applicant for you, in your organisation's name. The link is still returned in the response, and delivery tells you whether the email went out. Leave email out to deliver the link yourself: we hold no contact details for your users.

{ "steps": ["liveness"], "email": "ada@example.com" }

Request body

Request

curl "https://trust.myaza.app/api/kyc/verifications/ver_abc123/rerun" \
  -H "Authorization: Bearer $MYAZA_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "steps": ["liveness"], "email": "ada@example.com" }'

Response 201 Created

{
  "session": {
    "sessionId": "cmt1gfjce05g547grqbmjsiqf",
    "url": "https://trust.myaza.co/verify/pXk3...",
    "shortCode": "7K9F-2QHM",
    "expiresAt": "2026-08-22T12:00:00.000Z",
    "kind": "individual",
    "workflow": { "id": "wf_AbC123dEf456", "name": "Identity verification", "version": 3 }
  },
  "retryOf": "ver_abc123",
  "attempt": 1,
  "steps": ["liveness"],
  "full": false,
  "delivery": { "emailed": true, "reason": null }
}

When the applicant resubmits

Their resubmission is checked like any submission and completes the same verification. verification.completed (or verification.failed) arrives with the same verificationId and attempt counted up, and Get verification status reports the new result. You are charged for the steps the applicant redoes, not for the ones they keep.

A link stops working once it has been used, or once something newer replaces it. The applicant sees why when they submit:

Errors

Verifying again is allowed from any finished status, including a passed verification. Re-verifying someone whose document is about to expire is the same operation as retrying a failure.