BrandKwikID Documentation
API SuiteeKYC & DigiLocker

Authenticate

Verify PAN with holder demographics and explicit consent. Server-side POST with Bearer. Returns message plus transaction ids for reconciliation.

API reference

Try itLoading playground…
Loading…
AuthorizationBearer <token>

JWT Bearer token authentication. Obtain a token from the KwikID dashboard.

In: header

consentstring

User consent for this verification. Y proceeds when your policy allows; N when the user declines.

Value in"Y" | "N"
country_codestring

Country calling code for mobile_number (for example 91 for India).

dobstring

Date of birth of the PAN holder. Use YYYY-MM-DD unless your integration team specifies another accepted format.

Formatdate
fullnamestring

Full name as collected in your application for this verification.

mobile_numberstring

10-digit mobile number without the country prefix (use country_code separately).

Length10 <= length <= 10
panstring

10-character PAN (typically uppercase alphanumeric).

Length10 <= length <= 10

Response Body

curl -X POST "https://__mock__/verification/v1/panauthenticate" \  -H "Content-Type: application/json" \  -d '{    "consent": "Y",    "country_code": "string",    "dob": "2019-08-24",    "fullname": "string",    "mobile_number": "stringstri",    "pan": "stringstri"  }'
{
  "country_code": "string",
  "dob": "2019-08-24",
  "fullname": "string",
  "message": "string",
  "mobile_number": "string",
  "pan": "string",
  "requestid": "string",
  "transaction_id": "string"
}
{
  "detail": {},
  "message": "string"
}
{
  "detail": {},
  "message": "string"
}

Overview

Call POST /verification/v1/panauthenticate from your backend when you need to verify a PAN together with holder details you have already collected and explicit consent. You send:

  1. Authorization: Bearer <token> - your KwikID Verification API credential.
  2. JSON body - pan, fullname, dob, mobile_number (10 digits), country_code, and consent (Y or N), as documented in OpenAPI.

On success, the JSON body includes echoes of key inputs, a message (human-readable outcome), requestid, and transaction_id. Use ids for support and reconciliation; treat all fields as sensitive and avoid logging full payloads in plain text.

Key features

  • Demographic match: Sends PAN together with name, DOB, and mobile so verification can align with your onboarding data.
  • Consent flag: consent must reflect your legal workflow (Y or N).
  • Server-side only: Keep the Bearer token off devices you do not control.

Implementation

Prerequisites

  1. Valid Verification API credentials and HTTPS to <verification-api-base-url>.
  2. User consent captured per your policy before calling with consent: Y.

Step 1: Call from your backend

POST /verification/v1/panauthenticate HTTP/1.1
Host: <verification-api-base-url>
Authorization: Bearer <token>
Content-Type: application/json

{
  "pan": "ABCDE1234F",
  "fullname": "EXAMPLE HOLDER NAME",
  "dob": "1990-01-15",
  "mobile_number": "9876543210",
  "country_code": "91",
  "consent": "Y"
}

Replace placeholders with real values. mobile_number is 10 digits; country_code is the dial code without +.

Step 2: Use the response

On 200 OK, read message for the outcome text. Store transaction_id (and requestid if you use it) for audit and support.

Do: Correlate logs with transaction_id only; do not log full PAN or DOB in production logs unless policy requires it and storage is protected.

Do not: Return raw verification JSON to public browsers or embed the Bearer token in a client app.

Request flow

Error handling

HTTP statusWhen
400Validation failure (for example bad PAN length, missing field). See OpenAPI ValidationError.
401Invalid or missing Bearer token. See AuthenticationError.

Security notes

Warning: Request and response contain PAN and PII. Encrypt in transit (HTTPS), restrict access on disk, and follow your regulator and internal data-retention rules.

Benefits

  • Single POST to confirm PAN against holder details you already hold, with transaction_id for audit trails.
  • Clear consent field so product and legal teams can align the integration with policy.

Next steps