# Overview

> **Breaking change — effective 17 August 2026:** `Privy-Version: 2026-08-17.heimdall` standardizes response field names and changes `status` from `ok` to `success`. New integrations must send this request header. Inspect the `Privy-Version` response header to identify your current version, and review the [response changes and migration steps](/b2b-digital-certificate/changelog#17-august-2026-response-standardization) before adopting it.

Privy User Verification v2 verifies user identity data against an Authoritative
Partner before Privy issues a digital certificate. The API accepts identity
details, a selfie, and an identity-card image in one server-to-server request.

The integration has two operations:

| Operation | Purpose |
| --- | --- |
| `POST /api/v2/userverification` | Verify a user and return the certificate-issuance result. |
| `GET /api/v1/quota/user-verification` | Read the merchant's remaining User Verification quota. |

Every request uses HTTP Basic authentication and the `Merchant-Key` header.
Keep both credentials on the merchant backend.

## Verification flow

1. Collect the user's NIK, name, date of birth, email, and phone number.
2. Capture a clear selfie and identity-card image.
3. Convert both images to base64 strings.
4. Send the verification request from the merchant backend.
5. Check `userStatus` to determine whether the digital certificate was issued
   or held.
6. Store `transaction_id` for support and reconciliation.

The operation is synchronous. A successful HTTP response can contain either a
`verified` or `rejected` business result, so do not use the HTTP status alone to
decide whether the user passed verification.

Continue with the [quickstart](/b2b-digital-certificate/authoritative-partner-verification/user-verification/v2/quickstart), or
review the [request fields](/b2b-digital-certificate/authoritative-partner-verification/user-verification/v2/request-fields).