GST Verification API: The Complete Guide for Businesses

A GST verification API is a REST endpoint that takes a 15-character GSTIN and returns live taxpayer details from the GST system as structured JSON — legal name, trade name, current registration status, jurisdiction, places of business and return-filing history. It replaces the manual Search Taxpayer lookup on the government portal with something your application can call inside a signup form, an invoice-posting routine, or a nightly batch job over your whole vendor master.

This guide is the hub for everything we publish on GSTIN verification. It covers what the data actually contains, why a well-formed number proves nothing on its own, the workflows businesses build around it, and the questions worth asking before you sign with a provider.

What a GST verification API actually does

Every business registered under India’s Goods and Services Tax regime holds a GSTIN issued by the GST Network (GSTN). Those registration records are public: the government publishes a free Search Taxpayer page on gst.gov.in so that anyone about to transact with a business can look up who is behind a GST number. That page is designed for a human with a browser, a captcha and one number at a time.

An API exposes the same class of registration data over HTTP, in a form software can consume. You send a GSTIN, you get JSON. Nothing about the underlying record changes — what changes is that verification stops being a person’s job. If you have ever watched a finance team paste 400 GST numbers into a portal one by one before a quarter-end review, you already understand the entire value proposition.

Two terms get used loosely here and are worth separating. Validation is checking the string itself: length, character pattern, checksum. It happens offline, costs nothing, and is covered in detail in our breakdown of the GSTIN format. Verification is checking the number against the live registry. Only the second one tells you anything about the real world. We compare the two in API verification versus manual verification.

How one request works, end to end

The mechanics are deliberately boring, which is the point. Your application makes an authenticated GET request carrying the GSTIN in the path. The API validates the format locally, queries the taxpayer record upstream, normalises the result into a stable schema, and returns it. A well-behaved integration adds a client-side format check first, so obviously malformed input never becomes a billable request.

 curl -s https://gstinapi.com/api/get-taxpayer-info/27AAACR5055K1Z7 \
  -H "X-API-Key: YOUR_API_KEY" 

That is the whole surface area. There is no OAuth dance, no taxpayer consent step and no OTP, because you are reading a public registration record rather than acting on a taxpayer’s behalf. That is also the sharpest distinction between a verification API and a GSP integration: a GST Suvidha Provider is licensed by GSTN to file returns, generate e-way bills and push invoices to an Invoice Registration Portal (IRP) using the taxpayer’s own credentials. Verification needs none of that machinery.

The obvious alternative — scripting a browser against the portal — is a trap that looks cheap for about three weeks. Captchas, session handling, silent markup changes and rate blocks turn it into permanent maintenance, and you inherit the legal question of automating a government site you were never given API access to. We walk through the trade-offs in GST API versus scraping the GST portal.

What comes back in the response

The depth of the payload is where providers genuinely differ. A thin API returns a name and a status. A complete one returns the taxpayer’s whole compliance posture. Here is what a live lookup on this API actually contains.

These are not theoretical. A verified response for Reliance Industries Limited (27AAACR5055K1Z7, Maharashtra, Active) carries 354 filing records and 244 additional places of business. If you are designing a database schema around this data, size your tables for that, not for the two-row example in a quickstart.

Why format validation is not verification

This is the single most important idea on this page, and the one most often skipped. A GSTIN is structured, and the last character is a check digit computed from the first fourteen using a Luhn mod-36 algorithm. Map each character to its index in 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ, weight positions alternately 1 and 2 from the left, add floor(product / 36) + (product mod 36) for each, and the check character is charset[(36 - sum mod 36) mod 36].

It works, and it catches typos beautifully. It also catches nothing else. The algorithm is public, deterministic and trivially reversible, so anyone can produce a string that is 15 characters long, carries a plausible state code, embeds a real-looking PAN and passes the checksum — while never having been issued to anybody. A fraudster printing an invoice does not need to guess a valid GSTIN; they can compute one in a spreadsheet.

The same logic applies in reverse to search. People routinely want to go from a company name or a PAN to a GSTIN, and the honest answer is that those routes are far more limited than the GSTIN-to-details direction. We cover what actually works in searching a GST number by business name and searching a GST number using a PAN, and why looking up a GSTIN by mobile number is mostly a myth.

Where businesses plug this in

Verification is rarely a product on its own. It is a step inside a workflow that someone already runs, and the value comes from where you place it.

• Vendor and supplier onboarding. Check the GSTIN before the vendor record is created, so a cancelled registration never enters your master data. See GST verification for vendor onboarding.
• Accounts payable. Re-check at invoice posting, not just at onboarding. A supplier who was Active in April can be Cancelled by September, and you will not find out from the invoice. Automating vendor GST checks in AP covers the placement.
• Marketplace and platform seller KYC. Sellers self-declare a GSTIN at signup; a live check turns that declaration into a fact. See marketplace seller onboarding.
• Lending and underwriting. Registration age, filing regularity and turnover slab are cheap, hard signals about a borrower. GST verification for lending and NBFCs goes deeper.
• Invoicing and billing software. Auto-fill the legal name and address from the GSTIN at the moment a customer types it, and you eliminate an entire class of invoice-rejection.
• Periodic sweeps. Re-verify the whole vendor master on a schedule. Our bulk GSTIN verification guide covers batching, concurrency and how to store the diff between runs.

The compliance argument underneath all of these is input tax credit. Since ITC eligibility flows strictly from GSTR-2B — populated from your supplier’s GSTR-1 or IFF and gated through the Invoice Management System (IMS) — a supplier who does not file directly blocks your credit. Section 16(2)(c) also conditions your ITC on the supplier having actually paid the tax. Verifying registration status and filing regularity before you transact is not paperwork; it is protecting your own working capital. See the ITC rules explained and how GSTR-2B and IMS interact.

Choosing a provider: eight questions to ask

Most GSTIN verification vendors show you the same screenshot of the same JSON. These are the questions that actually separate them.

1. Is the response live, or cached? Ask directly, and ask for the cache TTL in writing. For a payment-release gate, a day-old status is not a status.
2. How deep is the payload? Name and status is table stakes. Filing history, delay analysis, QRMP preference and e-invoicing slab are what let you build a risk score rather than a yes/no.
3. What does “successful” mean for billing? You want to be charged for lookups that return data, not for malformed input or upstream timeouts. On this API, one credit equals one successful lookup.
4. Are the error codes documented and stable? An integration is only as good as its failure path. See our error code troubleshooting guide.
5. What are the rate limits, and what happens at the ceiling? A clean 429 with a retry hint is workable; a silent truncation is not. Rate limits, retries and webhooks covers designing for it.
6. Is there a bulk path? Onboarding one vendor and re-checking 40,000 of them are different engineering problems.
7. Can you try it before you talk to sales? Self-serve keys and a free tier tell you the product is finished. Ours gives you 20 credits on signup and a free public search tool with five lookups a day, no account.
8. Is the pricing legible? Per-lookup pricing you can read on a pricing page beats a quote you have to request.

A working integration in ten minutes

Sign up, copy the key, send the header. The endpoint is a single GET, and the response is JSON you can read without a schema reference. Here is a complete Python client with the two things people forget: a local format check, and a retry that distinguishes “try again” from “stop”.

 import re, time, requests

API = "https://gstinapi.com/api/get-taxpayer-info/"
HEADERS = {"X-API-Key": "YOUR_API_KEY"}
PATTERN = re.compile(r"^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z][1-9A-Z]Z[0-9A-Z]$")


def verify(gstin: str, attempts: int = 3) -> dict:
    gstin = gstin.strip().upper()
    if not PATTERN.match(gstin):
        raise ValueError(f"{gstin} is not a well-formed GSTIN")

    for n in range(attempts):
        r = requests.get(API + gstin, headers=HEADERS, timeout=15)
        if r.status_code == 200:
            return r.json()
        if r.status_code in (429, 500, 502, 503, 504):
            time.sleep(2 ** n)          # back off, then retry
            continue
        r.raise_for_status()            # 400/401/404: retrying will not help

    raise RuntimeError(f"verification failed for {gstin}")


data = verify("27AAACR5055K1Z7")
print(data["legal_name"], "-", data["status"]) 

The same shape works in any language — see the guides for Python, Node.js, Laravel, Java and Go, or start from the API documentation. If you are not writing code at all, the same lookup runs inside Excel and Google Sheets.

Three implementation notes worth internalising. First, store the response, not just the verdict — when a dispute surfaces eighteen months later, you want the payload as it stood on the day you paid. Second, timestamp everything; a verification is a statement about a moment, not a permanent property of a vendor. Third, decide what a Suspended status means in your workflow before you see one, because the middle of an escalation is a bad time to invent a policy. Our explainers on suspended GSTIN status and cancellation and revocation lay out what each state actually implies.

When you are ready to move past experimentation, the GST API product page covers the full feature set, pricing shows the per-lookup cost at each volume, and signing up takes about a minute and includes 20 free credits.

Frequently asked questions