Skip to content

Published services, current details, and clear categories.

Explore APIs

Automated Verification & Workflow APIs Built for Speed and Compliance.

Connect identity (KYC), business checks (KYB), banking, and document OCR through one unified REST integration.

  • Aadhaar numberXXXX XXXX 4321
  • PANXXXXX4321X
  • GSTIN24XXXXX4321X1Z5
  • Vehicle RCGJ05 XX 4321
  • Bank accountXXXXXXXX4321
  • Identity verifiedValidfull_namemasked id
  • PAN verifiedValidfull_namestatus
  • Business verifiedValidlegal_namegst status
  • Vehicle verifiedValidownerregistration
  • Account verifiedValidholder_namepenny drop
One integration, every check: send the identifier, get a verified result back in the same shape. Example values, masked the way the APIs return them.
  • Consent is a required field on every call, and each response carries a consent_ref
  • Every API answers with the same four fields
  • Pages for 8 industries

Why FinSour

Why teams choose FinSour for verification

Fast to call, quick to plug in, easy to watch, and broad enough to cover the whole onboarding journey on one integration.

  • Faster APIs

    Lean requests and one response shape, so your flow gets its answer and moves on. No polling, no second call to read the result.

  • 100+APIs

    100+ APIs available

    Identity, business, vehicle, banking and document checks for 8 industries, all on one key.

  • Plug-and-play APIs

    One key, one request shape, one response. Adding a check is a new path, not a new integration.

  • Groundbreaking dashboard

    Keys, usage and every call's result in one place, so engineering and operations read the same screen.

API categories

100+ APIs across 8 categories, and what each call does.

From identity and business checks to bank accounts, vehicles and documents, every category runs on the same key and the same response shape. Nothing is gated: the full catalog is one click away.

Browse 100+ APIs
Choose a category
POST/v1/aadhaar-verificationillustrative
An illustrative drawing of the KYC call. Every value in it is repeated in the steps beside it.

KYC

Consent comes first, and the Aadhaar number comes back masked

Your request reaches the source register only after the person agrees to this check, for a purpose you name. What comes back is already reduced. You learn who the holder is without receiving the full Aadhaar number you would then have to protect.

  1. You capture consent before the lookup, with the purpose recorded against it. The drawing uses customer onboarding, and a consent reference (cns_…) comes back beside the result.
  2. The customer then enters a six-digit one-time code, one cell at a time, the way they would in your own flow.
  3. The record comes back with aadhaar_number already masked to XXXX XXXX 4321. The first eight digits are never returned.
  4. Name and date of birth come back as the register holds them, both masked to *** in this sample.

The masking happens at the source, before the response reaches you. Nothing you store from this check holds a full Aadhaar number.

Explore KYC
POST/v1/utility-bill-ocrillustrative
An illustrative drawing of the Document OCR call. Every value in it is repeated in the steps beside it.

Document OCR

Send a photograph, get back named fields

The reader takes whatever the applicant uploaded, whether that is a phone photograph, a scan or a page from a stack. It reads the page once, top to bottom, and turns each zone into a field with a name you can use in code. The response carries those fields and no image.

  1. The slots carry their labels before the read starts. The field names stay the same when the document layout changes.
  2. One pass runs down the page, and each zone resolves as the pass reaches it.
  3. document_type comes back first. The reader names what it was given (IDENTITY CARD here) before reading anything off it.
  4. holder_name and document_number arrive already named, with the name masked to *** and the number ABCDE1234F. Nothing downstream has to read a position on the page.

This is the generic reader in the family. Most of the other endpoints run the same steps against one kind of document, such as an invoice, a payslip or a lab report.

Explore Document OCR
POST/v1/penny-dropsillustrative
An illustrative drawing of the Banking call. Every value in it is repeated in the steps beside it.

Banking

Does this account exist, and whose name is on it?

A penny drop credits one rupee to the account you are checking, then reads the registered name off the transfer that lands. You learn the name because a real credit went through and the bank says who accepted it.

  1. ₹1 leaves your float and travels to the account, against the IFSC in the request. This drawing uses EXMP0000123.
  2. The answer comes back along the same path, and it carries the registered name.
  3. The result records what it found and what it cost: name_at_bank masked to *** here, with ₹1 credited against the check that asked.
  4. Its sibling, penny-less, answers the same question with ₹0 moved. The request looks the same and the four response fields are the same. You hold no float and have nothing to reconcile.

The pair shows how the catalog is organised. Each endpoint stands on its own instead of arriving in a bundle, and both of these run on the same API key.

Explore Banking
POST/v1/vehicle-rc-verification-apiillustrative
An illustrative drawing of the Vehicle call. Every value in it is repeated in the steps beside it.

Vehicle

One number plate returns the whole registration

You send the number painted on the vehicle, and the filed registration comes back one row at a time. It names the vehicle and the class it was registered as. It also carries the two dates that decide whether the vehicle can legally be on the road today.

  1. You send rc_number exactly as it appears on the plate, such as MH 12 AB 1234.
  2. You get maker_model and vehicle_class as filed. The sample record returns LMV, a light motor vehicle.
  3. fitness_upto and insurance_upto are the two dates an operations team gates on. This record shows 2029-04-30 and 2027-01-22.
  4. The ring at the end pairs the plate you asked about with the registration that answered. The record repeats the number back. You can see a mismatch instead of assuming one.

You can reach the same registration from a chassis number or an engine number when you do not hold the plate.

Explore Vehicle
POST/v1/pan-to-gstillustrative
An illustrative drawing of the KYB call. Every value in it is repeated in the steps beside it.

KYB

A GSTIN resolves to a company and its other registrations

Fifteen characters resolve to a legal entity. You get the name it is registered under, whether the registration is live, and the date it started. The response then lists every other registration filed against the same business PAN.

  1. You send a 15-character GSTIN. You get legal_name exactly as registered, which reads SAMPLE TRADECO PVT LTD here.
  2. The registration comes back with a status you can read straight off it: ACTIVE, registered 2019-07-02.
  3. The record then opens out to the other registrations on the same PAN (ABCDE1234F in this drawing), each with the state it sits in.
  4. Two more GSTINs appear here, in Maharashtra and Delhi. That is how a branch nobody mentioned turns up before you onboard the business.
Explore KYB
POST/v1/aadhaar-esignillustrative
An illustrative drawing of the Legal call. Every value in it is repeated in the steps beside it.

Legal

Signing is the quick part. The call returns a status, a certificate reference and a timestamp, because the record that matters is the one you can produce in a dispute later. You do not get back a picture of a signed page.

  1. The agreement and the signatory's printed name sit on the page before anything happens.
  2. Authorisation comes first, shown masked as an Aadhaar consent reading XXXX XXXX 4321. That consent is what reaches the execution step.
  3. The signature is then drawn stroke by stroke, and the seal lands on the page after it.
  4. You get back a status of SIGNED, its reference and the time it was executed: ESN-0000-4821 at 2026-08-14 09:12 in this sample.

Other endpoints in the same family change the authorising step, such as a one-time passcode, an eStamp or a DSC held on a token. They return the same evidence.

Explore Legal
POST/v1/company-directorsillustrative
An illustrative drawing of the Corporate Registry call. Every value in it is repeated in the steps beside it.

Corporate Registry

From a company number to the directors who can sign

A corporate identity number (CIN) resolves to the filed company record, and that record leads to the board sitting on it today. Check the directors before you give a company credit. Then you know who can sign for it.

  1. You send a 21-character CIN. It resolves to the filed company: SAMPLE LOGISTICS PVT LTD, status ACTIVE.
  2. The record then branches, one line per officer, into the board as the register holds it today.
  3. Each officer returns as a DIN with the designation on file: managing director, whole-time director and independent director in this sample.
  4. A DIN identifies a person without naming them. Run the same number the other way to see every board that person sits on.
Explore Corporate Registry
POST/v1/e-invoicingillustrative
An illustrative drawing of the Tax & Compliance call. Every value in it is repeated in the steps beside it.

Tax & Compliance

Check an invoice against the register that issued it

You can check an invoice against the register that issued it before you pay it. The call builds the reference from the invoice's own fields. The answer covers this document and no other.

  1. The call reads three fields off the invoice and names them as it reads: supplier gstin, document no and document date.
  2. All three travel to the register together. The reference comes from the document itself.
  3. The invoice reference number (IRN) comes back row by row, with the acknowledgement date it was registered on: 14-08-2026.
  4. VALID applies to this invoice, and the signed QR code returns to the slot that was drawn empty at the start.

The consignment check in the same family works the same way for goods already in transit.

Explore Tax & Compliance

Why us

One integration, instead of a provider for every check

Most teams end up wiring a separate provider into every check they run. FinSour puts them behind one key, one request shape and one response, so the next check is a path, not a project.

The usual wayA provider per check
With FinSourOne integration for all of them
TopicA provider per checkFinSour
IntegrationsA provider per check: One per provider, each with its own docs and quirksFinSour: One REST integration for every check
CredentialsA provider per check: A key, a contract and an onboarding for each providerFinSour: One API key for the checks you turn on
ResponsesA provider per check: Every provider answers in its own shapeFinSour: The same four fields every time: success, message, data, status_code
ConsentA provider per check: Handled differently, or not at all, per providerFinSour: A required field on every call, with a consent_ref back
Adding a checkA provider per check: Another provider to evaluate and integrateFinSour: A new path on the integration you already have
Sensitive dataA provider per check: Full identifiers come back for you to store and protectFinSour: Aadhaar comes back masked to its last four digits

Get started

Tell us the journey you are building.

Send us the flow you are building, with the checks it needs and the order they run in. We come back with the endpoints that cover it, a sandbox key, and what those calls cost at your volume.

  1. Share your flowTell us the checks your journey needs and the order they run in.
  2. Get your endpointsWe come back with the APIs that cover it and a sandbox key.
  3. Go live on one integrationBuild against the sandbox, then switch to live on the same calls.