Full verification

Request

The endpoint imports the ID/selfie assets you already hold, runs the configured ID and selfie checks in sequence (waiting for each), drives the application to a terminal state so the configured Post-check / AML / Government checks run, and returns the full TS-native result — the same shape as Application detail.

This is the Service-API (JWT-authed) equivalent of the Platform Onboard API: same request/response shape, but not the same execution path. The lender is resolved from your JWT access token (like API Vision Score), and the server then generates an encrypted_token on your behalf and drives the request through the same underlying Onboard pipeline. That extra internal step is why this endpoint has two failure modes the Onboard API doesn't (see Failure codes): it can fail to generate that token (500), or fail while calling the underlying pipeline with it (502).

Use this when you already hold a user's ID/selfie assets (e.g. captured on another channel or by another vendor) and want to re-check them through the TrustVision pipeline in one call, without driving Init / Verify ID / Verify Selfie separately.

Note: the request blocks until all checks finish (ID + selfie run sequentially), so allow a generous client timeout.

Send the JWT access token in the Authorization header.

At least one of image1 (ID) or selfies (selfie) must be present — supply only one group for an ID-only or selfie-only re-check. Put liveness frames in videos, not in selfies.

The body is identical to the Platform Onboard API minus encrypted_token — authentication is handled by the JWT, so no token is sent in the body.

{
  "card_type": "vn.national_id",
  "image1": {
    "base64": "<base64_string>",
    "metadata": "{\"frame_index\":0}",
    "qr_code": [{ "result": "...", "from_image_type": "front" }]
  },
  "image2": {
    "base64": "<base64_string>"
  },
  "selfies": [
    { "base64": "<base64_string>", "metadata": "{\"frame_index\":0}" }
  ],
  "selfie_type": "passive",
  "videos": [
    {
      "frames": [
        { "base64": "<base64_string>", "label": "frontal", "index": 0 }
      ]
    }
  ],
  "flow_id": "full_verification",
  "card_types": "vn.national_id,vn.passport",
  "lang": "vi",
  "client_metadata": {
    "applicant_name": "<already-encrypted>",
    "id_number": "<already-encrypted>"
  }
}

Response

The endpoint blocks until all checks complete, then returns the full result — the same TS-native shape as Application detail (overall verdict plus each module's status). Conditional blocks (ekyc_ocr / ekyc_face / id_tampering / file_ids / form_data / client_metadata) appear only when the corresponding data exists.

Success (200):

{
  "data": {
    "verdict": "approve",
    "application_id": 10,
    "application_unique_token": "ad083945-...",
    "application_user_id": "0123456789",
    "ekyc_ocr": {
      "card_info": {},
      "process_status": "success",
      "sanity_check_status": "success"
    },
    "ekyc_face": {
      "compare_status": "matched",
      "compare_score": 0.98,
      "liveness_status": "live",
      "search_face_status": "not_found"
    },
    "id_tampering": { "score": 0.01, "verdict": "genuine" },
    "client_metadata": {
      "applicant_name": "<already-encrypted>",
      "id_number": "<already-encrypted>"
    },
    "access_token": "<JWT>"
  },
  "message": "onboard completed",
  "time": "2026-01-01T00:00:00Z",
  "verdict": "success"
}

Response data fields:

See Application detail for the full field reference, and The application result for the verdict, file_ids and form_data mappings.

Dedupe / indexing-only mode: when enabled for the lender (client_custom_settings.onboard_dedupe_only), the endpoint runs only face index/search, leaves data.verdict as pending, and returns the match result on data.ekyc_face.search_face_result / search_face_status (the Post-check / AML / verdict pipeline is skipped).

Failure codes