Service Level Agreement

This Service Level Agreement ("SLA") sets out the availability GSTIN API commits to for its GST verification API, how that availability is measured, what is excluded from it, and what you are entitled to when we fall short. It forms part of our Terms and Conditions and applies to every account, without a separate contract or a minimum spend.

The state of the service, and the availability we have actually measured, are published continuously on the status page. This document is the commitment; that page is the evidence.

1. What this covers

This SLA covers the GSTIN API gateway at gstinapi.com, specifically:

• The single-verification endpoint, GET /api/get-taxpayer-info/{gstin}.
• The bulk verification endpoints under /api/bulk/, including job submission, status and result retrieval.
• The authentication, credit accounting and result delivery those endpoints depend on.

It applies to verifications made against purchased credits. It does not apply to:

• Verifications made with free signup credits, which are a trial rather than a paid service.
• The free public lookup tool at /tools/gst-number-search, the offline validator and the other free tools.
• The marketing site, the blog and the documentation, which are not part of the API.
• Beta or preview features, which are labelled as such where they exist.

2. The commitment

GSTIN API commits to 99.5% uptime per calendar month for the endpoints listed in section 1.

We hold an internal availability target above this figure and publish what we measure against it. The number in this section is the level at which service credits become payable — the level we are prepared to stand behind commercially, rather than the level we aim for. Where the two differ, only this one has a remedy attached to it.

3. How uptime is measured

Availability is measured in five-minute intervals across the calendar month, in Indian Standard Time (UTC+05:30):

• Downtime is any five-minute interval in which the covered endpoints fail to return a valid response to well-formed, authenticated requests, for a reason within our control. An interval in which some requests succeed and others fail counts as downtime.
• Uptime for the month is the number of intervals that were not downtime, divided by the number of intervals in the month, after excluded intervals have been removed from both figures.
• Sources of truth. Our own monitoring, published on the status page, and your request logs. Either is sufficient to establish downtime. You do not need us to have declared an incident first, and an outage we failed to detect is still an outage.

Our monitoring runs inside the same infrastructure it measures, so an outage severe enough to stop the probe leaves a gap in the record rather than a run of failures. We publish the coverage of our own monitoring alongside the uptime figure so those gaps are visible, and a gap is resolved in your favour when a claim turns on it.

A response that correctly reports an upstream failure — for example HTTP 502 when the GST record provider is unavailable — is a valid response for the purposes of this section, and is covered by the exclusion in section 4. It is never billed: see section 7.

4. What is excluded

The following do not count as downtime. Intervals affected by them are removed from the calculation entirely rather than counted as available:

• Upstream unavailability. Outages, degradation, throttling or data errors at GSTN, the GST portal, or the GST Suvidha Provider network through which live records are read. This is the largest exclusion in this document and we would rather you noticed it here than discovered it during a claim. We monitor and publish upstream reachability on the status page regardless, because a lookup that cannot reach the register has failed from your point of view whether or not a contract covers it.
• Announced maintenance. Maintenance published on the status page at least 48 hours in advance, scheduled between 00:00 and 03:00 IST, and not exceeding 4 hours in total in any calendar month. Maintenance that is not announced that way is not excluded.
• Emergency maintenance required to address a security vulnerability or prevent imminent data loss, announced as soon as we reasonably can.
• Your side of the wire. Failures caused by your application, network, DNS resolution, firewalls or client libraries; requests that are malformed, unauthenticated or sent with an invalid or revoked API key.
• Credit exhaustion. Requests refused with HTTP 402 because the account has no credits.
• Rate limiting. Requests refused for exceeding a published rate limit.
• Suspension. Any period during which the account is suspended under the Terms and Conditions.
• Force majeure. Events outside our reasonable control, including regulatory direction, infrastructure-provider failure at a level we cannot route around, and acts of government.

5. Service credits

If measured uptime for a calendar month falls below the commitment in section 2, you may claim a service credit calculated on the amount you spent on verifications in that month:

How claims work:

• Email support within 30 days of the end of the affected month, with the approximate dates and times and, if you have them, sample requests or error responses. Log extracts are enough; you do not need to prove a root cause.
• We respond within five business days, either applying the credit or explaining, with reference to the measurement in section 3, why the month did not fall below the commitment.
• Approved credits are added to your verification balance within five business days and are valid for 12 months from the date they are issued. They are not refundable in cash and are not transferable between accounts.
• Service credits are the sole and exclusive remedy for any failure to meet this SLA.

6. Support response times

Support is by email and is included for every account at no extra cost. Business hours are 10:00 to 18:00 IST, Monday to Friday, excluding Indian public holidays. These are response times — the point at which a person has read your message and replied — not resolution times.

During a total outage we also update the status page, which is the fastest place to find out whether a problem is ours and whether we already know about it.

7. Billing during failures

Independently of anything in this SLA, and regardless of whether an interval is excluded under section 4, a verification is only ever billed when it returns a registration:

• Upstream errors, timeouts and unreachable-provider responses never consume a credit.
• A GSTIN rejected on its format or check digit never reaches the provider and is never billed.
• A well-formed GSTIN with no registration behind it is a real answer, and is not billed either.
• In a bulk job, only rows that resolve to a registration are charged, and duplicate GSTINs within one job are verified once and charged once.

In other words, you do not pay for our outages while they are happening, and the service credit above is on top of that rather than instead of it.

8. Latency

This agreement makes no contractual commitment on response time, and that omission is deliberate. We do not currently measure the latency of customer requests, so any percentile we published here would be an assertion rather than a measurement — and a verification's response time is dominated by a government upstream we do not control.

What we do publish is what our own monitoring observes, on the status page, with its method stated and its limits spelled out. If latency is a hard requirement for your integration, measure it yourself from your own network before you depend on it — how to benchmark a GST API sets out the method — and talk to us if you need something contractual, so we can tell you plainly what we are able to commit to rather than guess in a document.

9. Changes to this agreement

We may update this SLA as the service evolves. A change that reduces the commitment in section 2, widens the exclusions in section 4, or reduces the service credits in section 5 takes effect no earlier than 30 days after it is published here, and we will email account holders before it does. Every other change takes effect when published. The date at the top of this page is the date of the current version.

10. Questions

Procurement reviews, security questionnaires and requests for a countersigned version of this document are all welcome — get in touch. If your process needs a commitment this page does not make, tell us what it is and we will answer honestly about whether we can meet it.