Storing GSTIN Data: What the DPDP Act Means for Your App

Wiring up a GSTIN verification call takes an afternoon. The question that arrives a week later, usually from legal or from a customer's security review, takes longer: what exactly are we storing, on what basis, for how long, and who else can see it? India's Digital Personal Data Protection Act 2023 gives that conversation a legal frame, and a vendor master full of GSTINs sits in an interesting spot inside it. This post is the engineering answer, written for the person who owns the table.

The question every integration eventually hits

A GSTIN verification response is small and, at first glance, unremarkable: legal name, trade name, registration status, constitution of business, date of registration, state and centre jurisdiction, place of business, and often filing history. Nothing in it feels sensitive in the way a bank account or an Aadhaar number does.

Two things change that. First, some of those records describe individuals rather than companies. Second, the moment you store the response you have created a dataset — one that grows, gets copied into a warehouse, feeds a dashboard, and eventually ends up in scope for a security questionnaire or a breach. The right time to decide how to handle it is when the table is created, not when the questionnaire arrives.

Is a GSTIN personal data?

The DPDP Act protects personal data, meaning data about an identifiable individual. Whether a GSTIN qualifies depends entirely on the constitution of the taxpayer, and the structure of the number itself makes this legible: characters 3 to 12 are the PAN of the registered person.

Since a realistic vendor master contains all of these mixed together, and since nobody wants a conditional data-protection policy that branches on constitution of business, the workable engineering position is simple: treat the vendor table as containing personal data and apply one standard to all of it. It is cheaper than classification, and it is the answer that survives a customer security review.

Why you are allowed to hold it

The instinct on hearing "data protection" is to reach for a consent banner. That is the wrong shape here. You are not collecting data from an individual for your own marketing; you are checking a public business register to satisfy statutory conditions of your own — that a supplier is registered, that input tax credit is available, that an invoice is genuine, that you are not paying a fraudulent counterparty.

The DPDP Act accommodates this through processing that supports specified legitimate uses and legal obligations, and the GST law independently obliges you to hold supplier documentation and to satisfy the conditions for input tax credit. Asking a supplier's permission to check whether their GSTIN is valid would be an odd request, and refusing to check would not make you compliant with anything.

What this does not do is exempt you from the rest of the discipline. Purpose, minimisation, retention, accuracy and security still apply. In practice, write down the purpose once — "verifying the GST registration status of counterparties for tax compliance, onboarding and fraud prevention" — and then check every downstream use against it. Feeding your verification store into a sales prospecting tool is a new purpose, and that is where teams get into trouble.

What to store, and what to leave behind

Minimisation is easier to apply here than in most systems, because the audit purpose tells you exactly what earns its place: the fields that establish who the counterparty was and what their status was on a given date.

One anti-pattern worth naming, because it is extremely common: reducing the response to a boolean. A gst_verified column satisfies the form on the screen and is worthless as evidence, because it does not say what was verified, when, or against what. Keep the snapshot; the storage cost is a rounding error next to the credit it protects. We make the same argument from the tax side in what happens when a supplier's registration is cancelled retrospectively.

How long to keep it

Two clocks run at once, and the resolution is to let the purpose decide per record rather than setting one global TTL.

Records tied to a transaction or an active relationship should live as long as the tax record they support. Proceedings can be opened years after the event, and a verification snapshot whose entire value is proving what was true in 2026 is useless if it was purged in 2028. Align this with your GST record-retention policy rather than inventing a separate one.

Everything else should expire. Speculative lookups, prospects who never became vendors, duplicate checks during a bulk run, and cached responses used only to save an API call — none of these support a transaction, so none of them needs to outlive its cache window. A short TTL on the cache layer and a longer, purpose-bound retention on the audit table is the clean separation. The caching mechanics are covered in cutting your verification API bill.

Freshness deserves a word here too, because accuracy is a data-protection principle and not only a product concern. A status that was accurate when retrieved becomes misleading if the interface presents it as current. Show the retrieval date next to the status in any UI, and re-verify on a schedule rather than trusting a two-year-old snapshot — the pattern is in automated vendor GSTIN monitoring.

Securing the pipeline, not just the database

The database is usually the best-protected part of the system. The leaks happen at the edges, where data is copied for convenience and nobody thinks of it as a data store.

• Request and response logs. The default in most HTTP clients is to log the full exchange on error. That puts vendor names, addresses and your API key into a log aggregator with a different retention policy and a wider access list than your database.
• Error trackers. A failed parse commonly attaches the whole response body to the exception. Scrub payloads before they leave the process.
• Analytics and product telemetry. A GSTIN in a page URL or an event property ends up in a third-party analytics store you have not assessed.
• Support tooling. Screenshots and pasted payloads in tickets are a real, routine copy of the data outside your controls.
• Exports. The CSV a colleague pulled for a reconciliation is now on a laptop. Log exports, and prefer scoped views over full dumps.

On the credential side, the API key is the thing that turns a minor bug into a data-exposure incident. Keep it server-side — never in a browser bundle, a mobile app or a spreadsheet formula that ships to users — hold it in a secret manager rather than in source, scope it to a service, rotate it on a schedule and on any suspicion, and mask it in every log line. If you support multiple environments, issue separate keys so that revoking one does not take production down.

# Log the shape, never the payload.
logger.info(
    "gstin_verified",
    extra={
        "gstin_suffix": gstin[-4:],      # enough to trace, not to identify
        "status_code": response.status_code,
        "latency_ms": elapsed_ms,
        "cache_hit": cached,
    },
)

Then the ordinary controls: encryption in transit and at rest, least-privilege access to the verification tables, an access log for who read what, and backups covered by the same retention rules as the primary store — a deletion that leaves the record in nightly backups for a year is not a deletion in any sense that matters.

Your API vendor is a processor

When you call a verification API you are sending a GSTIN, and sometimes a name, to a third party. That makes them a processor acting on your instructions, and it makes their practices part of your posture. The questions worth asking before you integrate, and worth having answered in the contract:

1. What do they retain from your requests, and for how long?
2. Where is it stored, and is data kept in India?
3. Who are their sub-processors — including the GSP upstream of them?
4. What are their breach notification commitments, and on what timeline?
5. Can you delete your data on termination, and get confirmation?
6. Do they use your queries for anything beyond serving them — analytics, model training, resale?

The last one is the one people forget to ask and the one most worth asking. A supplier list is competitively sensitive information about your business, quite apart from any personal data it contains. On where the data originates in the first place, see where GST API data actually comes from and the GSP and ASP layers behind every provider.

The one thing not to build

Sooner or later someone proposes it: you have all this GSTIN data, why not publish a searchable directory — one page per GSTIN, with names and addresses, and let search traffic find it.

Do not. Verifying counterparties for your own compliance and republishing a register at scale are different activities with different exposure. A directory would necessarily publish the names and addresses of proprietors — identifiable individuals — for a purpose that has nothing to do with why the data was collected, and the operators who do this carry a standing takedown burden as a result. It is also, quite separately, the textbook thin-content-at-scale pattern that search engines devalue, so the traffic case is weaker than it looks.

The useful version of that idea is a tool that verifies a number the user already has, which is what our GST number search does: it answers a question about a specific GSTIN rather than publishing an index of everyone.

An implementation checklist

1. Write down the purpose for holding GSTIN data, in one sentence, before the first migration.
2. Treat the vendor table as containing personal data; do not branch policy on constitution of business.
3. Store the full response plus a retrieval timestamp and source, not a boolean.
4. Split storage: short-TTL cache for cost, purpose-bound audit table for evidence.
5. Tie audit retention to your GST record-retention policy; expire everything else.
6. Scrub payloads from logs, error trackers and analytics; log shape, not content.
7. Keep API keys server-side, in a secret manager, scoped and rotated.
8. Get processor answers in writing — retention, location, sub-processors, deletion, secondary use.
9. Cover backups and exports by the same retention and access rules as the primary store.
10. Show the retrieval date wherever a status is displayed, and re-verify on a schedule.

If you are still at the integration stage, the mechanics of the call itself are in how to verify a GST number using an API, the operational limits in rate limits and webhooks, and the failure modes in the error codes guide.

Frequently asked questions