Know your customer in minutes, not days.

Logging the server in

OAuth 2.0 client-credentials. The server trades its provisioned credentials for a short-lived bearer token — the phone never sees secrets.

Headers

Body

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 900,
  "expires_at": "2026-07-14T22:48:46Z"
}

Opening a session (TRN)

One call, no body. The returned UUID is the claim ticket for the whole onboarding.

Headers

{
  "transaction_id": "c5a21976-2e82-4ac0-b173-85aaa1e500a3"
}

Is this a live person?

Passive liveness on a single selfie frame. The cheapest fraud filter: printed photos and screen replays fail here.

Headers

Body

Sample response · 200

{
  "status": "success",
  "results": {
    "passed": true,
    "confidence_score": 0.82,
    "threshold": 0.8
  }
}

Reading the ID

OCR extracts printed identity + personal data into a standard JSON shape. Missing fields come back null — never guessed.

Headers

Body

Sample response · 200 (abridged)

{
  "status": "success",
  "extracted_information": {
    "id_information": {
      "code": "3",
      "type": "PNID",
      "id_number": "000-000-000",
      "expiration_date": "2026-12-12"
    },
    "personal_information": {
      "last_name": "Dela Cruz",
      "first_name": "Juan",
      "suffix": "Jr",
      "birthdate": "1990-01-01",
      "address": {
        "address_line_1": "45 Mabini Street",
        "barangay": "Barangay Poblacion",
        "city_municipality": "Makati City",
        "province": "Metro Manila",
        "zipcode": "1210"
      }
    }
  }
}

Does the face match?

1:1 biometric compare: the captured selfie against the captured ID portrait. Same TRN, verdict recorded as FACE_MATCH.

Body

Sample response · 200

{
  "status": "success",
  "results": {
    "is_matched": true,
    "confidence_score": 0.82,
    "threshold": 0.75
  }
}

Or verify by QR

For PhilSys cards: scan the QR, verify payload + selfie through eVerify. Same outcome, no ID photo needed.

Body

Sample response · 200

{ "status": "success", "is_verified": true }

Submitting for the verdict

Confirmed identity + captured photos go in; verification_status comes out: PASSED (PNID) or PENDING_REVIEW.

Body

{
  "id_information": {
    "code": "3", "type": "PNID",
    "id_number": "000-000-000"
  },
  "personal_information": {
    "last_name": "Dela Cruz",
    "first_name": "Juan",
    "birthdate": "1990-01-01"
  },
  "images": {
    "face_bio_base64": "<base64>",
    "id_front_base64": "<base64>"
  }
}

{
  "verification_status": "PENDING_REVIEW",
  "session_transaction_id": "c5a21976-…",
  "create_at": "2026-09-18T09:57:00Z"
}
// PNID path:
{ "verification_status": "PASSED", ... }

When things fail, they fail clearly

Every failure is HTTP status + error_code + human message. The demo surfaces all three in the backend log.

15 codes on the table

Guide §10 lists 14; the demo adds 0 = Other for anything the OCR can't classify. Contract scope applies: query only what our agreement covers.

The live demo maps 1:1

Three columns: the customer app, the backend log, results + docs. Every screen calls exactly one endpoint.