Bulk GSTIN Verification Speed and Throughput

"Which bulk GSTIN verification tool processes the most records per minute?" is the wrong question, and the vendors who answer it with a single number are answering a question about their marketing rather than your batch. Throughput is not a property of a provider. It is concurrency divided by per-call latency, bounded by a rate limit and by how heavily loaded the government systems are at the moment you run.

The good news is that this makes throughput something you control. This page gives you the arithmetic, the design that sustains a rate rather than spiking and collapsing, and a worked example for a 50,000-row vendor master.

The throughput arithmetic, in one line

Verifications per minute = (concurrent in-flight requests ÷ average seconds per request) × 60, capped by the provider's rate limit.

The table is arithmetic, not a promise — the right-hand columns are the realistic ones, and every row is subject to the rate limit on your account. Its purpose is to show you which lever moves the number. Halving latency and doubling concurrency have identical effects, and you control the second one directly.

What sets the ceiling — and it is not the provider

Four constraints bind, roughly in this order:

• The provider rate limit. A hard ceiling. Exceeding it returns 429 Too Many Requests, and retrying into a 429 wastes capacity you are still being measured against. Handle it properly — see rate limits, retries and webhooks.
• Upstream government load. Shared by every provider. On a filing deadline day, the per-call latency term in the equation above simply gets bigger for everyone.
• Your own infrastructure. Connection pool size, DNS resolution, database writes per result, and the worker count you actually have running. Batches often stall on the database write, not the API call.
• Error handling cost. Every retry is a call that produced no new record. A batch with a 15% retry rate is doing 15% more work for the same output.

The cheapest speed-up: verify fewer rows

Every call you do not make is infinitely fast and free. Real vendor masters are full of rows that do not need a call at all, and filtering them is worth more than any tuning.

1. Deduplicate on GSTIN. A supplier appearing on 40 invoice lines is one verification. Deduplicate before the queue, not after.
2. Reject invalid formats locally. The 15-character structure and mod-36 checksum are checkable in your own code in microseconds. Typos, truncated values and PAN numbers pasted into the wrong column all fall out here — see GSTIN format explained.
3. Skip anything already fresh. If you store verified_at, a row verified yesterday does not need re-verifying today unless it is at a decision point.
4. Tier by risk. Re-verify high-spend and recently flagged counterparties often, and the long tail quarterly. One cadence for everybody is what makes a batch large in the first place.

In practice these four steps routinely take a nominal 50,000-row file down to a much smaller number of real calls — which shortens the run and cuts the bill in the same motion.

A worker design that sustains its rate

The pattern that survives contact with a real 50,000-row file:

• One queued job per GSTIN, not one job for the file. A crash loses one record, not the run, and progress is inspectable at any moment.
• Rate limiting on the worker side, sized just under the provider limit, so you never rely on 429s as your flow control.
• Idempotent writes keyed on the GSTIN, so a retried job overwrites rather than duplicates.
• Exponential backoff with jitter on 429, 502, 504 and network errors — jitter matters, or every retry in the batch fires at the same instant.
• A dead-letter bucket for records that exhausted retries, reviewed at the end instead of blocking the run.
• A progress counter and an ETA, because a two-hour run with no visible progress will be cancelled and restarted by someone, which doubles the cost.

The full implementation, including CSV ingestion and reporting, is in the bulk GSTIN verification guide and bulk verification from a CSV upload.

Worked example: a 50,000-row vendor master

A procurement team with 50,000 rows in an export. What actually happens:

The second run of the same master is dramatically cheaper and faster, because most rows are inside the freshness window and only new or stale ones need a call. That is the shape a daily monitoring job takes — described in automated daily vendor GSTIN monitoring.

Measuring throughput honestly

Three rules keep a throughput number meaningful:

• Measure sustained, not peak. The first thirty seconds of a run always look excellent, because no retries have accumulated yet and no connection pool is saturated. Report completed verifications divided by total wall-clock time for the whole run.
• Count retries as work. A run that completed 30,000 records using 36,000 calls did 36,000 calls' worth of work and was billed accordingly. Report both numbers.
• Report completeness alongside speed. A batch that finished quickly because 8% of responses came back with null filing history did not finish; it produced 8% of records you will have to do again.

Track those three across two runs on different dates and you will have a far better answer to "how many records per minute" than any vendor can give you — because it will be an answer about your data, your infrastructure and your rate limit.

Frequently asked questions