How to verify a customer again with Myaza Trust
Ask an existing applicant to redo a finished verification, either fully or only for selected steps. Re-verification keeps the verification ID and records a new attempt so your team can explain what changed.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- A selected-step redo preserves the verification ID.
- The applicant sees the correction message.
- Old attempts remain available and old links cannot compete.
- A late old-attempt notification does not overwrite the new outcome.
Ask an existing applicant to redo a finished verification, either fully or only for selected steps. Re-verification keeps the verification ID and records a new attempt so your team can explain what changed.
Before you begin
Existing customer reference
Permission to request or review a verification
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Find the finished verification
Open the customer in Customers → Individuals or Businesses, then open the relevant verification. Check its subject, environment and ID before acting. Use Verify again for a finished workflow-based verification. An unfinished check may still return a result, so do not start a redo while it is processing. A verification without an available workflow needs the documented fresh-start path.
Integration reference: Verify again
Step 2: Choose the parts that need another capture
Select the steps the applicant must redo. For example, liveness asks for a new selfie; document-capture asks for document photos. Leaving steps empty requests the whole flow. Write a short applicant-facing message that explains the correction, such as retaking a dark selfie in better light. Keep already valid evidence unless your policy genuinely requires a full refresh.
Integration reference: Redo only what failed
Step 3: Choose the workflow version deliberately
Choose the original policy to run the original workflow snapshot or latest to use the currently published version. If you omit this, the workflow’s own rerun setting applies. Check whether a changed current policy affects what the applicant must provide. Do not assume the original and latest journeys ask for the same evidence.
Integration reference: Request body
Step 4: Create and deliver the new link
From your backend, call POST /api/kyc/verifications/{id}/rerun using a secret key and the selected steps, message and policy. Add email only if you want Myaza to send the link. Keep session.url private to the intended applicant; it is a credential. Check the delivery result. A failed email does not invalidate the returned link, so your own authorised delivery path can still use it.
Integration reference: Response 201 Created
Step 5: Keep the applicant on the latest attempt
The verification moves to awaiting_resubmission. Earlier links for the same verification stop working. Show the applicant the new link rather than sending several competing ones. If another reviewer decides the verification or starts a later redo, reconcile the current state. A superseded link is not a reason to create another customer record.
Integration reference: When the applicant resubmits
Step 6: Update the existing record when they finish
The next submission becomes another attempt on the same verification ID. Handle its latest final status and incremented attempt, retaining the earlier results. Chargeable work relates to the steps redone, not evidence kept from the previous attempt. Record the reason for the refresh and use the current outcome to update your application, rather than letting a late notification from the previous attempt overwrite it.
Integration reference: When the applicant resubmits
Get more from the capability
Use targeted redos for fixable capture issues and full redos for a genuine full-policy refresh.
Preserve previous attempts and reviewer rationale for support and audit.
Test both original and latest policy selection after changing a workflow, including links that were already sent.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
A selected-step redo preserves the verification ID.
The applicant sees the correction message.
Old attempts remain available and old links cannot compete.
A late old-attempt notification does not overwrite the new outcome.
Troubleshooting
The API says verification_in_progress
Wait for the current checks to finish and retrieve current status before another action.
The applicant’s old link stopped working
Use the newest valid link. Later reruns and decisions supersede earlier links.
No workflow is available
Check whether the original flow exists and is published; a non-workflow verification cannot be rerun through this contract.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
