Introducing VIDA Identity Stack: All of VIDA, in one place 🎉
For the complete documentation index, see llms.txt. This page is also available as Markdown.

SDK Response

Purpose Of This Page

Explains the structure of the SDK JSON payload, what each field means, and which values to extract before making backend API calls.

Step 1 - Parse the SDK Response

When the KYC SDK finishes on the mobile device, it delivers a single JSON payload to the host app. Your app must forward this to your backend. This payload contains all the identifiers you need to call VIDA's backend APIs.

Response Structure

Fields are erased when they do not apply. For example, warnings only appears when there is something to report, and backCardVerificationDetails is absent for single-sided documents.

Understanding the Identifiers

The response contains four different IDs.

ID
Scope
Use it for

verificationId

The whole KYC session

All session-level backend calls. This is your main identifier.

groupId

The whole KYC session

Same value as verificationId. Returned inside each operation for convenience.

sessionId

The whole KYC session

Same value as verificationId. Returned inside livenessDetails.

transactionId

One operation

Fetching the result of that one operation from VIDA.

partnerTrxId

One operation

Your own tracing and reconciliation. Not used to call VIDA APIs.

What to Extract and Store

Field
Where to Find It
Used For

verificationId

Top level

All backend API calls (

GET/api/v2/verify/status?verificationId=UUID)

failedOperation

Top level

Identifies which operation triggered onError. When this field is NOT null, the SDK session is considered terminal for this verificationId - no further retries or resume are possible. Use this as your primary signal for real-time failure detection. There is no need to poll the GET KYC Status API for failure cases; the API may continue to show IN_PROGRESS until the backend timeout expires. Null when the flow succeeded.

partnerTrxId

Per operation

Your own reference for tracing a single operation or attempt. Not returned at top level - use verificationId for session-level API calls.

frontCardVerificationDetails.transactionId

idCardVerificationDetails

GET /api/v2/transaction?transactionId=UUID - OCR/IDV front

backCardVerificationDetails.transactionId

idCardVerificationDetails

GET /api/v2/transaction?transactionId=UUID - OCR/IDV back

faceMatchDetails.transactionId

Top level

GET /api/v2/transaction?transactionId=UUID - Face Match

livenessDetails.transactionId

Top level

Liveness Service GET transaction (NOT My-Verify)

warnings[].code

Per card side

Alert logging - non-blocking.

Portrait image in ocrResult vs. documents API

The portraitImage field inside ocrResult is populated on-device by the SDK only - it is not returned in API responses.

The actual portrait image (extracted from the ID card) is available via GET /api/v2/transaction/{transactionId}?includeDocuments=true as a presigned URL in documents.portrait. See the Transaction Details API page for details.

Using SDK Response for KYC Decision-Making

The SDK callback response is your primary signal for real-time decision-making:

Success callback (failedOperation is null):

  • The SDK flow completed successfully.

  • Call GET /api/v2/verify/status?verificationId=UUID to confirm the VERIFIED status.

  • The API should return overallStatus: VERIFIED.

Error callback (failedOperation is NOT null):

  • The SDK session is terminal for this verificationId.

  • You may treat this as a failed verification immediately.

  • There is no need to wait for the GET KYC Status API to update.

  • The IN_PROGRESS status on this verificationId will auto-expire to FAILED after the configured timeout, but you should not wait for this transition to make your decision.

partnerTrxId in detail

It is per operation, not per session.

verificationId is the ID for the whole KYC session. partnerTrxId is the ID for one operation inside that session.

You will find partnerTrxId in three places:

  • frontCardVerificationDetails

  • backCardVerificationDetails

  • faceMatchDetails

It is not returned in livenessDetails.

How the value is created

The VIDA API does not accept the same partner transaction ID twice. Every operation must therefore receive a different value. How that value is built depends on whether you send one.

If you send partnerTransactionId when you start the SDK

The SDK uses your value as the base and adds a suffix (extra text added to the end of something. So id_f_1 added to the end of your value) for the operation and the attempt. There is no separator between your value and the suffix.

Operation
Suffix
Example

ID card front

id_f_1

YOUR-REF-001id_f_1

ID card back

id_b_1

YOUR-REF-001id_b_1

Face match

fm_0

YOUR-REF-001fm_0

The value in the response is not the same as the value you sent. Do not match on it directly. Store your base value on your side when you start the flow, or strip the suffix before matching.

If you do not send partnerTransactionId

The SDK generates a UUID for each operation, because the field is required by the VIDA API and can never be empty. In this case the three values are separate, unrelated UUIDs. They do not share a base and they have no suffix, so you cannot use them to group a session.

How to set it

Set partnerTransactionId when you build the SDK request.

How to use it

  • To find all data for one session, use verificationId.

  • To find one operation or one attempt, use partnerTrxId together with attemptedTransactionIds.

clientTransactionId is not an SDK Response field

clientTransactionId is a query parameter for the ID Fraud Shield (IDFS) GET API. It does not appear in the SDK response. When you call the IDFS API, use one of these values from the SDK response as your clientTransactionId:

SDK
Use this value

KYC SDK

groupId or verificationId

Liveness SDK

sessionId, partnerTrxId, or verificationId

Understanding Scores

Each OCR field, verification check, and image quality check includes a score and a threshold. Use the table below to determine what constitutes a passing result.

Check Type
Field
Passes When

OCR extraction

name, idNumber, dob, address, etc.

score >= threshold (confidence in extracted value)

Anti-spoofing

spoofingResult.recapScore, colorPrint, etc.

score < threshold (lower = less spoof-like)

Forgery detection

forgeryResult.summary

score < threshold (lower = less forgery-like)

Image quality

imageQualityResult.blurriness, lowLight

score < threshold (lower = better quality)

Landmark detection

landmarkResult.containerResult items

score > 0 (0 = not detected / occluded)

Sample SDK Responses

Sample 1 - partnerTransactionId passed (Malaysia MyKas)

The partner sent "Transaction ID". Note the suffix on each partnerTrxId, and the two failed liveness attempts.

Sample Response

Sample 2 - partnerTransactionId not passed (Malaysia MyKas)

The partner sent nothing, so the SDK generated a UUID for each operation. The three partnerTrxId values are unrelated to each other. This sample also shows a warning on the back card.

Sample Response

Last updated