PII inquiry with OTP | Vlens

This is the same PII inquiry as PII inquiry without OTP, with one extra call in front of it: you send an OTP to the phone number, the user reads it back, and you pass it along with the inquiry. That proves the person in front of you actually controls the number being validated.

Use this variant when phone-ownership matters — onboarding a new customer, or any flow where the phone number has not already been verified elsewhere in your product.

Same two endpoints, same response. The OTP variant adds one preceding call and two request fields: otpRequestId and otpCode.

The flow

Request an OTP

Call POST /api/FRAServices/RequestOtpForPii with the phone number. Vlens sends the code and returns an otpRequestId.

Collect the code from the user

The user reads the SMS and types the code into your app.

Submit the PII inquiry

Call either inquiry endpoint with the phone number, the ID (images or transactionId), plus the otpRequestId from step 1 and the otpCode the user typed.

otpRequestId and otpCode travel together. Send both, or send neither and use the no-OTP variant. Sending only one is rejected.

Step 1 — Request the OTP

POST /api/FRAServices/RequestOtpForPii

cURL

curl -X POST https://api.vlenseg.com/api/FRAServices/RequestOtpForPii \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "phoneNumber": "PHONE_NUMBER"
  }'

Field	Required	Description
`phoneNumber`	Yes	The phone number to send the code to. This must be the same number you validate in step 2.

{
  "data": {
    "otpRequestId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
  },
  "error_code": 0,
  "error_message": null
}

Keep the otpRequestId — you echo it back on the inquiry call.

Step 2 — Submit the inquiry

Pick the endpoint that matches what you hold.

With ID images

POST /api/FRAServices/PersonallyIdentifiableInformation

cURL

curl -X POST https://api.vlenseg.com/api/FRAServices/PersonallyIdentifiableInformation \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "idFrontBase64Image": "BASE64_ENCODED_IMAGE",
    "idBackBase64Image": "BASE64_ENCODED_IMAGE",
    "phoneNumber": "PHONE_NUMBER",
    "otpRequestId": "OTP_REQUEST_ID",
    "otpCode": 123456
  }'

Field	Required	Description
`idFrontBase64Image`	Yes	Base64-encoded front of the national ID.
`idBackBase64Image`	Yes	Base64-encoded back of the national ID.
`phoneNumber`	Yes	The phone number being validated.
`otpRequestId`	Yes, for this variant	The value returned in step 1.
`otpCode`	Yes, for this variant	The code the user received, as a JSON number — `123456`, not `"123456"`.

With an existing transaction

POST /api/FRAServices/CheckIdAndFRAByTransaction

cURL

curl -X POST https://api.vlenseg.com/api/FRAServices/CheckIdAndFRAByTransaction \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "phoneNumber": "PHONE_NUMBER",
    "transactionId": "TRANSACTION_ID",
    "otpRequestId": "OTP_REQUEST_ID",
    "otpCode": 123456
  }'

Field	Required	Description
`phoneNumber`	Yes	The phone number being validated.
`transactionId`	Yes	The `transaction_id` returned by the OCR or Digital Identity capture that processed the ID images.
`otpRequestId`	Yes, for this variant	The value returned in step 1.
`otpCode`	Yes, for this variant	The code the user received, as a JSON number — `123456`, not `"123456"`.

Response

Identical to the no-OTP variant — see Response for the full payload and every field.