Overview

What this documentation covers and how it is organised.

The platform exposes verification APIs for identity, business, professional, financial and vehicle checks — for example PAN, Aadhaar, Bank, Driving Licence, Passport, GST, MCA/CIN, FSSAI, RC and credit-bureau (CRIF / CIBIL) report APIs.

• Left navigation — groups all APIs by category. Pick a category, then pick an API and version.
• Every API page — shows the endpoint, required headers, request schema, response schema, live code snippets, and a playground to try the API.
• This guide — teaches you how to read each of those sections and make your first successful call in minutes.

Before You Begin

Three things you need for every API call.

1. Base URL

   The environment you are calling. Production: https://prod.authenticateindia.com

2. Client ID

   Your API key, sent in the x-client-id header. Issued to you when your account is created.

3. Product Instance ID

   Your tenant identifier, sent in the x-product-instance-id header. It decides which product subscription and configuration your call uses.

Authentication Headers

Every request must carry these headers.

Anatomy of an API Page

Every API page (for example Pan Verification) is built from the same blocks. Here is what each block means, top to bottom.

4.1 — Title and version

The page title is the API name with a version badge such as V1 or V2. Always check the badge — different versions can accept different request fields.

4.2 — Description

One or two sentences under the title telling you what the API does and when to use it. Read this first — several APIs look similar (Pan Verification vs PAN Detail) but return different data.

4.3 — Method and endpoint

The HTTP method (almost always POST) and the path to append to the base URL. A few endpoints take a value inside the path — e.g. /api/verify/{transactionId}/status, where you replace {transactionId} with the ID you received earlier.

4.4 — Headers table

4.5 — Request schema

This is the exact JSON body the API expects. For every field it tells you:

• Name — copy it exactly (case and spelling). Field names differ between APIs (pan, pan_number, pannumber, id_number …); a wrong name makes the API treat the value as missing.
• Type — request fields are strings unless marked otherwise.
• Constraints — a regex the value must match. Validate on your side to avoid a 400.
• Example — a realistic sample value you can test with.

4.6 — Request playground

The right-hand panel generates ready-to-run code for the page you are on. It contains the environment tabs, the Base URL box with a copy button, the language selector and a Try-it-out action that executes the request with the sample payload and shows the raw response.

4.7 — Response schema

Shows what the API returns on success (HTTP 200). For example, the PAN Detail API returns a data array in which each record has:

• pan_number — the PAN that was verified
• full_name — name as per PAN records
• gender and dob — demographic details on record
• category — PAN holder category
• date_of_birth_match — true / false: did the DOB you submitted match the record
• name_as_per_pan_match — true / false: did the name you submitted match the record
• aadhaar_seeding_status — whether the PAN is linked to Aadhaar

The boolean match flags are usually the actual verification result your business logic should act on — the surrounding fields let you show the user what was matched.

4.8 — Response inspector

Below the snippet, the inspector shows the HTTP status (for example 200 OK) and a full sample response body, so you can compare your real response against the documented one field by field.

4.9 — Code snippets

Auto-generated, copy-paste-ready request code in curl and C#. Only the placeholders need replacing.

Making Your First API Call

Five steps from page to response — shown with the PAN Detail API.

1. Open the API page

   Use the left navigation to find the API (for example Pan Verification → PAN Detail).

2. Check the request schema

   Note the exact field names, types and constraints. For PAN Detail you need pannumber matching the PAN regex.

3. Copy a snippet

   In the Request Playground pick your language and copy the generated code.

4. Replace the placeholders

   Swap {{base_url}}, {{client_id}} and {{product_instance_id}} for your real values.

5. Send and inspect

   Run the request. A 200 with a populated data array means success — compare it with the sample in the Response Inspector.

curl --location --request POST 'https://prod.authenticateindia.com/api/verify/pan-detail' \
--header 'x-product-instance-id: YOUR_PRODUCT_INSTANCE_ID' \
--header 'x-client-id: YOUR_CLIENT_ID' \
--header 'Content-Type: application/json' \
--data-raw '{
    "pannumber": "ABCDE1234F"
}'

var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Post, "https://prod.authenticateindia.com/api/verify/pan-detail");
request.Headers.Add("x-product-instance-id", "YOUR_PRODUCT_INSTANCE_ID");
request.Headers.Add("x-client-id", "YOUR_CLIENT_ID");
var body = new
{
    pannumber = "ABCDE1234F"
};
request.Content = new StringContent(
    System.Text.Json.JsonSerializer.Serialize(body),
    System.Text.Encoding.UTF8,
    "application/json");
var response = await client.SendAsync(request);
var result = await response.Content.ReadAsStringAsync();
Console.WriteLine(result);

Request Body Rules

Conventions that apply across the API family — knowing these prevents most 400 errors.

• Exact field names. Always copy field names from that page's schema — pan, pan_number, pannumber, id_number and imei_no all exist on different APIs.
• String values. Unless the schema says otherwise, send every value as a JSON string — including dates, years and consent flags.
• Date formats differ per API. Use exactly the format shown in the schema:

• Consent-based APIs. Some verifications (e.g. Pan Verification) require "consent": "Y" and a short "reason" describing why you are verifying. Omitting them fails the request.
• Validate before you send. Check values against the schema regex (PAN, GSTIN, TAN, pincode, mobile patterns are documented per field) — the API rejects malformed input with a 400.

Reading the Response

What a successful (HTTP 200) response looks like and how to interpret it.

Successful responses return the verified record(s) inside a data array. A PAN Detail response has this shape:

{
  "data": [
    {
      "pan_number": "ABCDE1234F",
      "full_name": "rahul sharma",
      "gender": "MALE",
      "dob": "01-01-1990",
      "category": "Individual",
      "date_of_birth_match": true,
      "name_as_per_pan_match": true,
      "aadhaar_seeding_status": "Y"
    }
  ]
}

• Match flags (date_of_birth_match, name_as_per_pan_match) are booleans — they tell you whether the values you submitted match the official record. This is the verification decision.
• Record fields (name, gender, category, seeding status) come from the source system — display them to your user or store them for audit.
• Empty or non-matching result? A 200 can still carry match = false or an empty data set — the call succeeded; the verification simply did not match. Handle both cases in your logic.

Status Codes

What the HTTP status tells you, and what to do next.

Best Practices

• Validate client-side first — regex-check PAN, GSTIN, mobile, pincode etc. before calling.
• Copy field names from the schema — never from memory.
• Act on match flags — treat *_match booleans as the verification verdict.
• Persist transaction IDs for asynchronous flows and poll status instead of re-submitting.
• Log request identifiers (not credentials) so any issue can be traced with support quickly.
• Watch the version badge — re-check the schema before switching versions.
• Protect credentials — keep both ID headers server-side and rotate the key if exposed.