How to confirm contact details with Myaza Trust
Verify contact access with an email or phone code. Use the workflow step for capture journeys, or the standalone API when your app needs a separate contact check.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- Correct, wrong and expired codes take different paths.
- A verified challenge can be reconciled after response loss.
- Repeated sends respect rate limits.
- A proved contact is recorded only against its intended customer.
Verify contact access with an email or phone code. Use the workflow step for capture journeys, or the standalone API when your app needs a separate contact check.
Before you begin
Supported delivery channel
Customer access to the email address or phone
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: Choose workflow or standalone verification
For a verification journey, open your workflow and enable Email Verification, Phone Verification, or both. Use a contact-scoped workflow when you only need to refresh an existing customer’s contacts. For an independent code entry screen in your app, use the standalone contact API on your backend. Do not mix its proof with a separately billed SDK contact step.
Dashboard example: Choose workflow or standalone verification
Step 2: Configure the workflow code step
Select Email Verification → Setup. Review Required to proceed, Code length, Max attempts and Code input style. Configure the enabled phone step separately. Keep the attempt limit and expiry recovery clear to customers. Review contact-specific rules such as disposable-email findings, then save and publish the workflow before creating new sessions.
Dashboard example: Configure the workflow code step
Step 3: Send a standalone code from your backend
Call POST /api/kyc/contact/verifications with channel set to email or phone and the destination. Include country for national phone formats and your stable externalUserId when recording proof on an existing customer. Store the returned challenge ID, normalised destination and expiry. Sandbox does not send a real message; its delivery channel is test.
Integration reference: Send a code
Step 4: Check the code against its challenge
Ask the person to enter the code, then call POST /api/kyc/contact/verifications/{id}/check with code. Use the challenge ID returned by the send call. Do not mark the contact verified when a message is sent. Check for status: verified. In Sandbox the code is all zeros at the configured length. Never expose a secret key in the code-entry screen.
Integration reference: Check the code
Step 5: Handle expiry, wrong codes and uncertainty
Codes last five minutes. Show the remaining attempts for a wrong code; an exhausted or expired challenge needs a new send. After a lost check response, retrieve GET /api/kyc/contact/verifications/{id} to reconcile it. Re-checking a verified challenge does not charge again. Avoid repeated sends to the same destination; the documented hourly limits are separate from wrong-code attempts.
Integration reference: Read a challenge
Step 6: Store the proved contact and interpret signals
Store the normalised destination and verified timestamp in your application. With a matching existing entity, externalUserId lets the service record OTP-verified evidence there; it does not create a missing entity. Use disposable, virtual and other signals only when present. Possession of a mailbox or phone is not a complete identity check. Review the current rate before using Production.
Integration reference: What the signals tell you
Get more from the capability
Keep the send, challenge and customer bound together so a code cannot verify another customer’s contact.
Treat unknown line type or MX evidence as unknown. Fire policies on recorded findings, not missing values.
Use workflow contact steps before expensive capture checks when that sequence fits your onboarding policy.
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.
Correct, wrong and expired codes take different paths.
A verified challenge can be reconciled after response loss.
Repeated sends respect rate limits.
A proved contact is recorded only against its intended customer.
Troubleshooting
No Sandbox message arrived
That is expected. Sandbox uses the test delivery channel and an all-zero code.
A national phone number is invalid
Supply the correct two-letter country or use an international dial-code format.
The contact is not on a customer record
Check externalUserId and that the customer already exists in the same organisation and environment.
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.
