The GST Developer Portal: What It Is and How to Get Access

Most developers arrive at the GST developer portal the same way: a ticket says "verify vendor GST numbers", a search turns up developer.gst.gov.in, the page looks like an official API portal, and the obvious next step seems to be signing up for a key. Then the signup is not there. There is documentation, there are schemas, there is a sandbox mentioned — and no button that gives you credentials. This post explains why, what the portal is genuinely for, and which of four routes fits the thing you are actually trying to build.

What the GST developer portal actually is

When GSTN built the GST system it had to solve an integration problem at national scale. Millions of registered businesses run thousands of different accounting, ERP and billing products, and every one of those products eventually needs to talk to the tax system — to file a return, fetch a ledger, generate an e-way bill. None of that software can be permitted to connect directly to core tax infrastructure, for reasons that are obvious the moment you imagine the alternative.

The answer was a documented API surface plus a vetted intermediary tier. The GST developer portal is the documented half. It publishes the specifications for the GST system APIs, the request and response schemas, authentication and encryption requirements, version history, and release notes when an API changes. It also acts as the working reference and credential-management surface for the organisations that hold a connection.

What it is not is a developer platform in the sense the phrase usually implies. There is no free tier, no instant key, no dashboard where you paste a GSTIN and watch a response come back. The portal documents a system you reach through a contracted relationship, and the contract is the hard part — not the code.

What sits behind the login

The API surface documented through GSTN's developer programme covers the authorised workflows — the operations that read or write a specific taxpayer's own records. Broadly:

Notice the last row. It is the only one that does not require the taxpayer to authorise you, and it is the one the overwhelming majority of teams asking about portal access actually need. We come back to that distinction in public vs authorised data, because getting it right is usually the difference between a two-day integration and a two-quarter procurement.

Who is allowed in — and who is not

Production credentials for the GST system APIs are issued to GST Suvidha Providers. A GSP is an entity GSTN has selected and contracted: it holds the direct connection, meets GSTN's infrastructure and security requirements, and is accountable for how it handles taxpayer data. The empanelled list is finite, published by GSTN, and runs to a few dozen names — a mix of large IT services firms, tax-technology companies, banks and telecom operators.

Everyone else builds on top. An Application Service Provider builds the product you actually use — the reconciliation dashboard, the e-invoicing module inside an ERP, the verification endpoint your code calls — and reaches GSTN through a GSP's connection. There is no register of ASPs and none is needed, because the accountability chain runs from you to the ASP, from the ASP to its GSP, and from the GSP to GSTN. We covered that architecture and the buyer questions it raises in the GST Suvidha Provider list explained.

The two portals people confuse

A great deal of wasted effort comes from treating GST API access as one thing. It is two, run by different bodies, with separate credentials, separate sandboxes and separate eligibility rules.

That fourth row is the one worth internalising. The e-invoice side is materially more open: a taxpayer above the e-invoicing threshold can register for API credentials on their own GSTIN and call the IRP directly, without a GSP in the middle. If e-invoicing is what you are building, you are in a better position than the GST developer portal would lead you to believe — we walk that path end to end in the e-invoice API developer portal guide.

Public data vs taxpayer-authorised data

This is the distinction that decides which route you need, and it survives every layer of the architecture intact.

Taxpayer-authorised data is a specific business's own records: its ledgers, its filed returns, its liabilities. Reading it requires that taxpayer to authorise you, typically by enabling API access on their own GST portal login and completing an OTP flow. No licence substitutes for that consent — a GSP cannot read your ledgers because it is a GSP, it reads them because you authorised it. If that is your requirement, see how to enable API access in the GST portal, which is the step your customer performs, not you.

Public taxpayer data is the registration record: GSTIN, legal name, trade name, registration date, status, taxpayer type, constitution of business, state jurisdiction, and return filing history. No consent is required from anyone to read it, because it is published precisely so that counterparties can check who they are dealing with. This is why verification APIs can be sold cheaply, by the call, with no onboarding ceremony — and why needing one is not a reason to go anywhere near empanelment.

Your four realistic options

Laid out honestly, with what each actually costs you:

1. Buy a verification API. For reading public taxpayer data on any GSTIN. An API key in minutes, per-call pricing, no empanelment, no consent flow. This covers vendor onboarding, KYB, accounts payable checks, marketplace seller verification and invoice validation — the large majority of requirements that start with a search for the developer portal.
2. Buy an ASP product backed by a GSP. For filing, ledger access or reconciliation on behalf of consenting taxpayers. You integrate with the ASP; the ASP handles the GSTN relationship. Ask which GSP they route through and whether that arrangement is current.
3. Register directly on the NIC e-invoice portal. Available to taxpayers above the e-invoicing threshold, for IRN and e-way bill operations on your own GSTIN. Genuinely self-service, with a real sandbox.
4. Pursue GSP empanelment. Only if being the connection is your business. Months of procurement, ongoing compliance obligations, and criteria most software companies do not meet.

The comparison of those routes on cost, lead time and what each one unlocks is worked through in GST API for developers: which access route you actually need.

Sandbox and test credentials

Every team asks about sandboxes early, usually because they want to build against something before commercial conversations start. The honest position differs by portal.

GSTN's sandbox for the core system APIs is available to empanelled entities as part of onboarding. It is not open to the public, and no amount of searching will surface a working set of shared test credentials — the ones circulating on forums are expired, revoked, or were never valid.

The NIC e-invoice sandbox is open to registered test users and is the more useful of the two for anyone learning the shape of Indian tax APIs. You can register, get sandbox credentials, and generate test IRNs against schemas that match production.

For verification specifically, commercial APIs generally give you free credits rather than a separate sandbox environment, which is more useful anyway — you are testing against live data with real responses rather than fixtures that drift from production. If you want known-good inputs to test error paths and validators, we maintain a set in test GSTIN numbers for testing, and the checksum algorithm lets you generate structurally valid numbers offline without spending a call.

Frequently asked questions