Verification APIs with one integration to maintain.
Read the request and response shape before you write any code. The sections below show how an integration goes together, and what moving onto one integration removes from your code.
Service families
- Banking ServicesBank account, UPI, and face-match services for secure payment and onboarding workflows.
- Legal ServicesDigital signing, stamp-duty, and certificate-verification services for compliant document workflows.
- KYC ServicesAadhaar, PAN, Voter ID, passport, driving licence, and KYC document OCR services for secure customer onboarding.
- KYB ServicesBusiness identity, registration, and business document OCR services for confident merchant onboarding.
- Corporate Registry ServicesCompany, director, and corporate identifier lookups for onboarding, diligence, and vendor checks.
- Tax & Compliance ServicesGSTIN, e-Way Bill, and e-invoice verification services for tax, billing, and goods-movement workflows.
- Vehicle ServicesVehicle registration, compliance, toll-tag, and vehicle document OCR services for mobility workflows.
- Document OCR APIsOCR services for utility bills, invoices, IDs, statements, receipts, reports, and other customer documents.
What this reference covers
Both figures are counts of what the catalog publishes, read from the catalog itself when this page was built.
Verification APIs
Service families
Every endpoint, with the request and response shape
Every published endpoint, grouped by family, from a catalog of 100+ verification APIs. The worked example below uses PAN Verification API. Every other endpoint takes the same request shape and returns the same four fields, with only the path and the body fields changing.
You can read and copy the samples here. Nothing on this panel sends a real request.
PAN Verification API
KYC Services
Body
pan_numberABCDE1234F10 charactersconsentYrequired on every callResponse
200 · Verified{ "success": true, "message": "Verified", "data": { "client_id": "pan_kyc_9f3ac2e7b1d4", "pan_number": "ABCDE1234F", "full_name": "***", "category": "Individual", "status": "VALID" }, "status_code": 200}- One field to branch onEvery endpoint returns true or false here. You write one check instead of a result parser per endpoint.
- What happened, in wordsA record that is not found comes back in the same four fields, with a message you can branch on. There is no thrown error to catch.
- The only part that changesThe fields inside data differ by endpoint because the source records differ. The three keys around them stay the same.
- The same four fields, every timeWhen you add another check, the error handling you already wrote keeps working. You point the same client at a new path.
The samples use sandbox fixtures drawn from the catalog. No figure on this panel is a measurement. FinSour publishes no latency, uptime or volume figures per endpoint, and this page does not invent any.
Three steps from sandbox key to production
Here is the whole integration, in the order you would do it. Every step below calls a published endpoint, read from the live catalog.
What consolidating onto one integration removes
Most teams arrive with three vendor SDKs and three sets of keys to rotate. A spreadsheet often stands in for the consent log. Moving onto one integration usually removes more code than it adds.
- vendor contracts31
- API keys in production31
- consent stores1 sheet0
- retry policies31
- error paths to write31
One bearer token reaches every endpoint in the catalog. The client is a thin typed wrapper around HTTP. A plain fetch works just as well.
1 file changed, 11 insertions(+), 13 deletions(−)
Ready to take a sandbox key?
Tell us which checks your flow needs. Our team sets up your API access and walks through the first integration with you.