Title Verification for Your Platform: Build, Buy or Use an API

Picture a product that sits near Indian real estate: a listing site, a fractional-ownership app, an escrow flow or the lending stack of an NBFC. Sooner or later someone using it asks a question it has no answer for. 'Is this property clean?' The screen has photos, a price, locality scores and maybe a RERA number, yet nothing says whether the title is sound, whether a court case is attached, or whether ownership snapped three transfers ago.

Deals collapse and trust drains away at exactly that point. Here is how platforms deal with it. We look at the pieces that make up a title check, what it honestly costs to build one across 28 states with your own people, and when a property verification API in India is a better choice than a team of scrapers.

Reasons platforms add verification

Product roadmaps feel three pressures here.

One is conversion. Put two identical listings side by side and the one with a verified-title badge wins, since it takes away the buyer's biggest unspoken worry. Where the ticket is large, trust is what runs short, and an outside verification badge supplies a signal that your brand cannot produce on its own.

Another is regulation. The Real Estate (Regulation and Development) Act, 2016, or RERA, placed disclosure duties on developers and on platforms. A marketplace that publishes clean records with their sources faces fewer mis-selling complaints.

The last is differentiation. After a single portal in your category launches verification, every competitor is playing catch-up. Escrow and fractional-ownership products are a clear case: it is hard to justify holding a buyer's money against a property no one has examined.

The building blocks of a title check

It sounds like a single feature, yet verification is really four engineering problems on top of each other.

First comes record fetch: pulling the encumbrance certificate, the registered sale deed, the mutation and property-tax records and the survey or revenue record, every one of them from a separate state government portal. Next is document analysis, where the PDFs are read and the parties, schedule of property, survey numbers and encumbrance entries are extracted. Third, court search asks whether the property, its seller or its survey number shows up in any litigation, pending or closed. Last, legal synthesis combines it all into an opinion a person can read: clean, conditional or rejected, along with reasons that a buyer can act upon.

Leave out a single layer and the property remains unverified. All you have done is put a document on screen.

Deciding between build and buy

Buy it or call an API. Build in-house only if verification is what you sell, rather than a feature of something else.

Any CTO will follow the logic. Every one of the four layers has a long tail of edge cases. The data underneath comes from government portals that change with no warning, no version number and no changelog. What you take on is not one integration but the upkeep of 28-plus of them, tied to systems with no duty to keep working for you. Upkeep is a running cost, not a one-off build cost, and running costs compound.

One exception is genuine. Where verification reports bring in your revenue, you should own the pipeline. Anyone who embeds verification as a trust layer within a different core product will seldom find the build cost justified.

Building it, without sugar-coating

An estimate means little until you can see the work behind it, so here is what a build involves.

A patchwork of 28 state portals

No national API for land records exists because land belongs to the states. Registration data in Andhra Pradesh is handled in one way, in Telangana in another, and the same goes for Maharashtra and Karnataka. Logins work differently, document formats differ, field names differ, and the way an encumbrance certificate is requested and displayed has its own oddities. 'Record fetch' therefore means writing and maintaining one scraper for every state you want to cover, and even within a state the formats shift from one district to the next.

Monthly scraper breakage

When a state portal is redesigned, moves an endpoint, renames a form field or changes how sessions are handled, nobody tells you. A scraper that ran fine in March may quietly return nothing in April. Integrations we have supported show that this is routine and not rare, a steady stream of upkeep. You need monitoring that spots a failed fetch before a customer does, plus engineers on call to fix scrapers anywhere in your state footprint. Teams underrate this item more than any other.

What captchas and rate limits cost

Captchas guard most government portals, and requests are throttled by IP and by session. Running at volume means paying a captcha-solving service for each solve, rotating IPs, and keeping pools of sessions so you are not locked out. The cost per report is tiny, but it becomes real at scale and rises with each state and each concurrent request from your platform.

Covering courts is a separate project

Do not treat litigation search as a side task. Figures that the National Judicial Data Grid publishes show that eCourts covers over 18,000 courts and hundreds of millions of case records at district and taluka level. Matching a property or a seller against that mass of data, with variants of names, transliterations and partial matches, is a search and entity-resolution problem by itself, apart from the land-record scrapers.

Someone has to sign off in law

Fetched documents bundled together are not an opinion. A person with legal training must read the encumbrance entries, notice a break in the ownership chain, and judge whether a finding is a red flag or merely a clerical artefact. In-house lawyers can do this, or an AI layer reviewed by lawyers can. Either way the cost recurs, and the quality standard cannot be dropped without giving wrong answers on decisions where a lot of money is at stake.

What a build realistically takes

Treat these as typical ranges and not as a promise. Covering a meaningful number of states in-house normally takes a small dedicated team, with engineers on the scrapers and orchestration and legal expertise on the opinion layer. Expect close to a year before coverage is broad and reliable, and then a permanent maintenance crew to keep the scrapers running. The build is not the headline cost. The team you must keep on afterwards is, and for most platforms that settles the question.

Buying it: verification through an API

With a property verification API, you hand over a property identifier or a set of documents. Record fetch, document analysis, court search and legal synthesis all run behind a single endpoint, and a structured verification result comes back for your platform to use. Portal scrapers, captcha handling and court-data infrastructure are not yours to operate. It is called like a payments API or a KYC API.

Product teams are best served by report-as-a-service over REST. Your system POSTs a property reference and gets a job in return. Verification takes time, so a webhook callback signals completion, and no request is held open. The backend remains asynchronous, and users watch progress and not a spinner.

On the front end, embeddable widgets let you place a verification status card, or a flow to request verification, inside your existing interface without rebuilding anything. With white-label outputs, the report carries your product's brand and not the vendor's, and the trust it earns is yours.

Ways to integrate that work well

Most platforms are covered by three patterns.

Verify-on-listing triggers a check as soon as a seller or agent posts a property, so every live listing shows a status before a buyer arrives. It is the conversion play, since clean listings receive a badge and the badge sells.

Verify-on-offer triggers the check at the moment of intent, once a buyer makes an offer or pays an escrow deposit. You spend on verification only for properties that have real demand, which fits escrow and fractional products, where money is about to move.

Badge-with-rating shows a short verdict with its sources on the listing card, namely a clean, conditional or flagged status and a grade. Paired with a property rating model, it gives the buyer one signal that is easy to read in place of a 30-page document that nobody opens.

How to judge a verification API

Five features separate an API you can use from a demo.

Coverage: which states are included and how deeply. Ask whether it truly fetches encumbrances and registered deeds in the geographies you target, or only in the easy ones. Latency: the wait between request and result, and whether it is steady enough for you to set user expectations. Evidence artifacts: whether the response carries the source documents and a trail of citations, or only a verdict you have to accept blindly. Audit logs: whether months later you can rebuild exactly what was checked and when, a necessity in any regulated or money-handling flow. Webhook signing: whether callbacks on completion are cryptographically signed, letting your backend confirm that a payload came from the vendor and was neither forged nor replayed.

If a vendor cannot demonstrate signed webhooks and evidence artifacts, read its verdict as marketing and not as verification.

LegiScore as a case in point

The integration surface that this article describes is how LegiScore exposes its pipeline. REST APIs submit and fetch verifications, signed webhooks deliver completion callbacks, and embeddable widgets and white-label report outputs serve front-ends. Platforms call the engine that runs LegiScore's own product.

On output, LegiScore says its full legal opinion has 29 sections and takes under 15 minutes, covering record fetch, document analysis, court search and the synthesised verdict. Its listed prices are Rs.199 for a title search, Rs.1,999 for a full title opinion, and Rs.499 per file for volume use. Platforms that run verify-on-listing across an inventory will care most about the bulk tier.

For a build-versus-buy choice the cost comparison settles it. A fee per file against an inventory is variable, so you can model it and pass it on. A permanent team maintaining scrapers in 28 states is fixed and exists whether you run one verification a day or ten thousand. For most platforms that embed verification and do not sell it, the variable cost is the better deal.

Side-by-side summary

• Time to launch · Build in-house: roughly 6-12 months to reach broad coverage · Verification API: a matter of days to integrate REST + webhook
• State coverage · Build in-house: just what you build and keep up · Verification API: the vendor's footprint, from the first day
• Maintenance · Build in-house: a standing team that repairs scrapers · Verification API: handled by the vendor
• Cost profile · Build in-house: fixed, made up of team + captcha + infra · Verification API: variable, a fee for each file
• Evidence quality · Build in-house: only as good as your legal layer · Verification API: source docs + opinion, if the vendor supplies them
• Court data · Build in-house: a separate eCourts project · Verification API: part of the pipeline