GST API Uptime and Latency: What to Measure

If you are choosing a GSTIN verification API for enterprise use, the honest answer to "which one is fastest and most reliable" is that no published number should decide it for you. Every GST verification API in India reads the same government source, so the differences between providers sit in a narrow band — and the biggest single factor in your observed latency is not the vendor at all, it is what the GSTN systems are doing at that moment.

What separates a good provider from a poor one is therefore not a headline millisecond figure. It is how they behave when the upstream is slow: whether they time out cleanly or hang, whether they return a structurally complete payload or a fast empty one, and whether their error responses tell you enough to retry correctly. This page is how to measure that.

The four numbers that actually matter

Providers tend to quote one number. You need four, and they should all be measured from your own infrastructure rather than from a status page.

That last row deserves emphasis, because it is where fast and correct pull against each other. Any provider can serve a lookup in 40 milliseconds by returning something it fetched last week. Speed claims are only meaningful alongside a stated cache window — ours holds upstream taxpayer responses for a window measured in hours rather than days, matched to how often the underlying record actually changes, and we say so in the pricing explainer.

Why average response time is the wrong metric

Consider two providers over 1,000 calls. Provider A returns every call in 400 milliseconds. Provider B returns 950 calls in 120 milliseconds and 50 calls in 6 seconds. Their averages are 400ms and 414ms — functionally identical. But if you are verifying a GSTIN inside a signup form, Provider B fails 5% of your users with something that looks like a broken page, while Provider A never does.

The average erased the only thing you cared about. Collect percentiles from the first day of your evaluation, and set your alerting on p95 rather than on the mean, because the mean will stay reassuring through an incident that is already costing you signups.

The part of the latency no provider controls

A GSTIN verification is not a read from the provider's own database. It is a read from the government data supply chain, and that chain has its own load pattern. Around the GSTR-1 and GSTR-3B filing deadlines — the 11th, 13th and 20th of the month in the usual monthly cycle, covered in GST return due dates — the underlying systems carry enormously more traffic than on the 5th. Response times across every downstream API rise together.

Two practical consequences follow. First, when you benchmark, do it on at least one deadline day and one quiet day, or your numbers describe a world you do not live in. Second, if you run bulk re-verification of a vendor master, schedule it for the quiet part of the month. That single scheduling change usually does more for your observed p95 than switching provider ever would.

How to benchmark a provider yourself in an afternoon

This is worth doing properly, because it is the only evidence that describes the provider as you will actually experience it — from your network, with your GSTINs, at your times of day.

1. Build a realistic sample. Take 200 to 500 GSTINs from your own vendor or customer master, not a curated list. Include known-cancelled and known-suspended ones deliberately: how a provider represents a cancelled taxpayer matters as much as how fast it says it.
2. Call each provider from the same machine. Same region, same egress, same client library, sequential rather than parallel for the first pass so you are measuring the API and not your own connection pool.
3. Run three passes. One at a quiet hour, one at peak business hours, one on a filing deadline day. Record for every call: HTTP status, wall-clock duration, and a boolean for whether the payload contained the fields you depend on.
4. Report percentiles, not means. p50, p95, p99, plus the error rate split into 4xx, 5xx and "200 but incomplete". That last bucket is the one that will surprise you.
5. Repeat the worst case deliberately. Point the client at an unreachable host and at a deliberately malformed GSTIN. Confirm your timeouts fire when you expect and that the error body is specific enough to act on — see GST API error codes.

Reading an uptime SLA without being misled

An SLA is a contract, not a measurement, and the interesting text is never the percentage. Four questions decide whether a "99.99%" figure means anything to you:

• What is being measured? Almost always the provider's own gateway. If their gateway answers every request in 50ms with an upstream-unavailable error, that hour may count as fully available under the contract while none of your verifications succeeded.
• What is excluded? Scheduled GSTN maintenance is excluded by essentially every provider, and reasonably so — but it means the SLA does not cover a meaningful share of real downtime.
• What is the remedy? Usually a service credit proportional to the affected period. On a pay-as-you-go account verifying a few thousand GSTINs a month, that credit is worth a few rupees. It is not a risk transfer; it is a signal of seriousness.
• Who declares the incident? If only the provider can declare one, and only from their own monitoring, your evidence of an outage does not start the clock.

Our own position is deliberately plain, and it answers all four questions in one place. The gstinapi.com SLA commits to 99.5% uptime per calendar month on our gateway — for every pay-as-you-go account, with no enterprise contract to sign — backed by service credits of 10% to 50% of that month's spend. It says in the same breath that GSTN and GSP upstream outages are excluded, that your own request logs are enough to open a claim without us declaring an incident first, and that we contract no latency figure at all, because we do not yet measure customer request latency and will not sell a percentile we have not observed. What we do measure is published live on the status page, method and gaps included. Treat any provider that will not describe its exclusions in the same detail as its percentage with corresponding caution.

Designing so a slow upstream never becomes your outage

The highest-leverage reliability work is on your side of the wire, and it is the same work regardless of which provider you pick.

• Never block a user-facing request on a verification. Accept the GSTIN, validate its format and checksum locally — see GSTIN format explained — then verify asynchronously and update the record. Signup completes at your speed, not the government's.
• Set an explicit, short timeout — a few seconds, not the client default of none — and retry with exponential backoff and jitter, as covered in rate limits and retries.
• Fail closed on decisions, open on display. If verification cannot complete before a payment run, hold the payment for review. If it cannot complete before rendering a vendor's name on a dashboard, show the cached value with its age.
• Store verified_at beside every cached record so that "we could not reach the API" and "this record is three weeks old" are distinguishable states in your own data.
• Alert on completeness, not just on 5xx. A rise in 200-but-empty responses is the earliest warning you will get that the upstream is degrading.

Do those five things and a bad upstream hour becomes a queue that drains slowly rather than an incident. Skip them and no vendor's SLA will save you, because the failure will be in your call site rather than in their gateway.

Frequently asked questions