Live vs cached GST data: why a GSTIN check should hit the source

A GSTIN record has fields that change: the registration status, the cancellation date, a suspension, a change of name or address. An API that answers from a stored copy is accurate only up to the moment it last fetched, and it has no way to know whether the registration changed since.

The cost of that is lopsided. A cache that is hours or days old is right almost every time, which is exactly why it feels safe, and wrong on the one occasion that matters: a supplier whose registration was cancelled yesterday, or whose cancellation was made effective from an earlier date. Under Section 29(2) of the CGST Act a cancellation can carry a retrospective date, and an officer may suspend a registration while proceedings are pending. A verification that returns "Active" from last week's copy answers a question you did not ask.

Every lookup on gstinapi.in, whether it comes from the REST API, the free checker on the site, a bulk upload, a PAN search or an MCP tool, goes through one function that calls the live upstream provider each time. There is no store in between that it could read from. We checked this in the code on 4 October 2026: the cache table that exists in the database schema is not read or written by anything.

"Live" here means live from our upstream provider on the GST network. We have no official statement on how quickly a change on the GST portal reaches that provider, so we do not claim the data is the same second as the portal, only that we add no delay of our own.

The visible consequence is also the easiest test: every successful call is billed once. Two identical calls are two charges and two lines in your usage log, because both really went upstream.

Vendor monitoring is different by design. It exists to tell you what changed, which means comparing today's record with the last one, so it keeps snapshots. These are reused for efficiency across accounts watching the same GSTIN: a stored snapshot is reused only if it is younger than 80% of the shortest watcher's check interval (about 19 hours for a daily watch), and the filing-history portion of a snapshot can be reused for up to 7 days. If the upstream call fails, monitoring keeps the previous snapshot and tries again next cycle.

The monitoring dashboard also shows the latest stored snapshot rather than making a live call when you open it. None of this touches the lookup API: if you need the current state of a GSTIN right now, call the lookup endpoint.

Two things. First, a cost per check: a lookup costs a credit, and a re-check costs another. If you check the same GSTIN a hundred times a day you pay a hundred times, where a cache would make repeats free. Second, latency: the calls we made on 4 October 2026 for the same public GSTIN returned in between 73 and 468 milliseconds measured at our server, the slowest being the bundled complete-profile call, which makes several upstream requests.

If you want to avoid repeat charges, the sensible approach is to decide how fresh each use needs to be and store the result yourself with its timestamp: re-check at onboarding, before each large payment and at renewal, and use monitoring for the days in between. That puts the freshness decision where the risk is.

1. Take a GSTIN you know to be active and look it up twice, a few seconds apart. Check the response time and your usage log or balance. A call served from a cache may be noticeably faster the second time, and may not show up as a fresh request in your usage.
2. Ask the provider, in writing, whether lookups are ever served from stored data and for how long. A clear "no" or a clear "up to N hours" are both answers you can design around. A vague one is not.
3. Look for a timestamp on the data. If a record says when it was last refreshed at the source, you can judge its age yourself.