Where GST API Data Comes From: GSTN, GSPs, Accuracy

Every honest GSTIN verification API in India reads the same underlying record — the public taxpayer registration data that GSTN maintains and that the Search Taxpayer page on gst.gov.in renders as HTML. No provider has a private, better copy of it. So when a vendor tells you their data is "the most accurate, direct from the GSTN portal", the claim is either trivially true of everyone or it is marketing.

The questions that do distinguish providers are narrower and much more useful: how many hops sit between you and GSTN, how long a served record may have been sitting in a cache, what happens to the response when the upstream is unavailable, and whether the payload is complete or quietly truncated. This page explains the chain and gives you a test you can run in an hour.

The chain a GSTIN lookup travels down

Between your curl and the government record there are up to four links, and knowing which one your provider occupies tells you most of what you need.

More hops mean more places for a record to be cached and more places for an error to be swallowed and re-presented as an empty success. That is the real cost of a long chain — not accuracy in the sense of wrong values, but opacity about how old a value is and what happened when it could not be fetched.

What a GSP is, and when you need one

The GSP framework exists so that software can interact with GST systems on a taxpayer's behalf. A GSP is authorised by GSTN to connect to its APIs, and that authorisation carries real obligations around security, audit and infrastructure.

The distinction that matters to you is between reading public data and acting on a taxpayer's behalf:

• Reading public taxpayer data — legal name, trade name, status, registration date, constitution, principal place of business, filing history, e-invoicing eligibility — is reading information the government already publishes for anyone to look up. This is what a verification API does, and what you almost certainly need.
• Acting on a taxpayer's behalf — filing GSTR-1 or GSTR-3B, generating an IRN, creating an e-way bill — requires that taxpayer's authorisation and filing-grade access, which is where a GSP is genuinely necessary. That path is described in return filing and reconciliation APIs and e-invoice status and IRN tracking.

Vendors sometimes use "GSP-backed" as a general trust signal on products that only do the first thing. It is not a lie, but it is not the reassurance it sounds like either. For verification, ask instead about freshness and failure behaviour.

How fresh the data really is

Nearly every provider caches, including us, and caching is the correct engineering decision — a taxpayer's registration record does not change minute to minute, and re-fetching it on every call would make the service slower and more expensive for no benefit. The problem is an undisclosed cache.

Our position, stated plainly: we hold upstream taxpayer responses for a window measured in hours rather than days, matched to how often the underlying record actually changes. Filing history and status move on the timescale of return periods and registration actions, not seconds.

Read that table alongside your own workflow and the freshness question becomes concrete. Populating a dropdown with a trade name? A day-old record is fine. Releasing a payment against an invoice, or claiming input tax credit? You want status read close to the decision, because that is precisely the field that can have changed since you last looked.

Accuracy, completeness and staleness are three different problems

They get bundled into the word "accuracy", which is why the word is nearly useless in a procurement conversation. Separate them:

• Stale. The values are correct as of some earlier moment. Common, usually harmless, dangerous exactly at decision points. Fixed by disclosure and a documented cache window.
• Incomplete. A 200 OK arrives, but filing_data is null or the address object is empty because an upstream sub-call failed and the provider returned what it had. This is the most under-measured failure in the category, because your monitoring counts it as a success.
• Wrong. The value does not match the government record at all. Genuinely rare, and when it happens it is usually a parsing or normalisation bug on the provider side rather than bad source data.

Instrument for the middle one. A rule as simple as "if status is present but filing history is null, treat this as a failed verification and retry" catches more real problems than any accuracy SLA.

How to test any provider accuracy claim yourself

An hour of work, no vendor cooperation required.

1. Pick 30 GSTINs you can independently check — your own entities, and a mix of active, cancelled and suspended registrations from your vendor master.
2. Look each one up on the GST portal manually and record legal name, trade name, status and registration date. This is your reference set. Note the time.
3. Call the API for the same 30 and diff field by field. Anything that differs is either staleness or a genuine defect — a cancelled registration still showing Active tells you the cache window is longer than advertised.
4. Time two identical back-to-back calls. If the second returns dramatically faster, you have measured their cache. Ask them to confirm the window.
5. Break it on purpose. Send a well-formed but non-existent GSTIN, and a malformed one. A provider that returns a clean, distinguishable error for each is one you can build reliable logic against; one that returns 200 with an empty body for both is not. See GST API error codes.

Six questions that separate a source from a reseller

1. What is your cache window for taxpayer registration data, in hours?
2. Do you call GSTN through your own GSP relationship, or through another API provider?
3. What exactly do you return when the upstream times out — an error, or a 200 with partial data?
4. Which fields can be null in a successful response, and under what circumstances?
5. Is a cached response billed as a verification, and is it flagged as cached?
6. When the GST portal has an outage, what does your API do for the duration?

Specific answers to those six tell you more than any accuracy percentage. Vagueness on question two or three is itself the answer. The wider provider comparison lives in choosing a GST verification API provider, and the case against rolling your own is in GST API versus portal scraping.

Frequently asked questions