GST API vs Manual Lookup — Why Hardcoding Rates Is a Compliance Time Bomb

Three approaches to GST rate lookup in your Indian application. Two of them will give you a compliance notice within 18 months. Here is the honest breakdown — no sales pitch, just what actually happens to each approach in production.

The three approaches every Indian developer uses

Option A: Hardcode a rate table. You copy the GST rates from a government PDF into a JSON file, a database table, or a switch statement. Ship it. Zero ongoing cost.

Option B: Scrape the GST portal. You write a scraper that hits services.gst.gov.in and extracts rates on demand. Feels clever. Feels like you built something.

Option C: Use a GST API. You call an endpoint that returns the correct rate in JSON. Pay a monthly fee. Move on.

Most developers start with Option A. Here is what happens 6 months later.

What goes wrong with hardcoded rates

The GST Council meets roughly every 2–3 months. Each meeting produces notifications that change rates across dozens of product categories. In September 2025, the Council restructured the entire rate schedule — eliminating the 12% slab for most goods and moving them to either 5% or 18%, and introducing a new 40% slab for luxury and demerit goods.

Every developer who hardcoded rates before September 2025 was producing incorrect invoices the morning after that notification went live.

The second problem with hardcoded rates is conditions. India's GST structure is not flat. The same HSN code can attract different rates depending on whether the product is branded or unbranded, pre-packaged or loose, supplied B2B or B2C, intrastate or interstate, below or above a price threshold. A hardcoded table cannot resolve conditions. It returns one number. That number is wrong for a significant percentage of your transactions.

For example: unbranded basmati rice (HSN 10063012) is taxed at 0%. Branded, pre-packaged basmati rice is taxed at 5%. If your hardcoded table says 5% for all basmati rice, you are over-collecting GST from customers buying unbranded stock — and under-collecting for the reverse. Both create liabilities.

What goes wrong with portal scraping

Scraping services.gst.gov.in seems like the smart middle ground — you are reading live government data, so it is always current. Here is what actually happens:

GSTN blocks aggressive scrapers. The portal has rate limiting and IP blocking. Any application doing more than a handful of lookups per minute will get blocked. In production, when your checkout process calls the scraper, it times out, your customer sees an error, and you lose the sale.

The portal structure changes without notice. When the government redesigned the portal in 2024, dozens of scraper-based applications broke overnight. No changelog, no API versioning, no migration guide. Your regex patterns stop matching and you have no fallback.

Response times are 3–15 seconds. A government portal is not optimised for API throughput. Your checkout flow that should complete in under 2 seconds now takes 17 seconds because it is waiting for a government website to respond.

Rate change lag. GST Council notifications are published and implemented at the same time. Your portal scraper reads whatever the portal currently shows — but government portals sometimes take 24–72 hours to reflect new rates after a council notification. During that window, you are still scraping stale data.

What a production GST API gives you

A GST API built for production — not a hobbyist project — solves all of the above. Here is what to look for and what to verify before you integrate.

Always-current data. The API should update within 24 hours of any CBIC notification. Not "when we get around to it." Within 24 hours, with a documented update policy and a webhook to notify you when rates change.

Condition resolution. The rate returned should not be a flat number. It should be the rate that applies to your specific supply — with the condition evaluated against your parameters. See the CGST/SGST/IGST explainer for how supply type alone changes which tax applies.

Notification reference in every response. Every rate returned should include the exact CBIC notification that authorises it. When your CA questions a rate six months later, you need to show them: Notification No. 09/2025-CT(Rate), Schedule II. Without that reference, you have a number with no legal backing.

Under 200ms response time with a guaranteed SLA. Not "usually fast." A documented 99.5% uptime guarantee with a response time commitment.

What a real API response looks like

# POST gstaccelerator.in/v1/lookup
# Headers: X-API-Key: your_key

{
  "description": "branded basmati rice, pre-packaged",
  "supply_type": "intrastate",
  "branded": true
}

# Response
{
  "hsn_code": "10063012",
  "tax_rates": {
    "cgst": 2.5,
    "sgst": 2.5,
    "igst": 5.0
  },
  "condition_applied": "pre-packaged and labelled",
  "notification_ref": "09/2025-CT(Rate), Schedule I",
  "effective_date": "2025-09-22"
}

Notice what is returned: CGST and SGST separately (because supply_type is intrastate), the condition that triggered the rate, and the exact notification reference. This is what a compliance audit trail looks like. See the full API documentation for all parameters and response fields.

Free vs paid GST APIs — what the tiers actually mean

Free tiers are for integration testing, not production. Here is why that distinction matters.

A D2C store with 5 orders per day generates approximately 15 GST lookup calls per day — product classification, invoice generation, and a rate validation check. That is 450 calls per month. A 100-call free tier covers less than a week of production traffic.

That is the forcing function by design. Free tiers let you build and test with zero friction. The moment you go live, you need a paid tier. The question is what you are paying for.

When to use a GST API — specific use cases

• E-commerce checkout. Every product on your platform has an HSN code. Every invoice needs the correct CGST/SGST split. Hardcoding means touching code after every GST Council meeting.
• Billing and invoicing SaaS. Your customers are CAs and business owners. One wrong rate on one invoice creates a compliance liability. A GST API with notification references converts that liability from yours to provably-correct.
• ERP and Tally integrations. Product masters have 10,000+ SKUs. Classifying each one manually takes weeks. A bulk classification endpoint turns that into an overnight job.
• AI agents building invoices. Any agent that writes purchase orders or classifies products needs a reliable GST tool call. The MCP endpoint makes this native.
• CA firm tools. Bulk HSN classification for client inventory at ₹0.08 per call on the Pro plan. Cheaper than one hour of a junior CA's time.