I already had per-invoice billing working: reserve a credit, do the expensive call, settle or refund. Then I added a bulk endpoint — paste a list, verify them all — and the neat single-item model fell apart, because in a batch some rows cost money and some are free, and you don't know which is which until you've done the work.

This is the metering design behind the bulk GSTIN verification tool on GSTExtract — a solo GST SaaS — and the two bugs I hit building it. The interesting part isn't the happy path. It's that "charge for a batch" quietly becomes "charge for the subset of the batch that turned out to be billable, without overselling and without spending the paid API on rows the user can't pay for."

The setup

A user pastes up to 50 GST numbers. For each, I call a paid third-party registry API and return the business name, status, and address. Each fresh API call costs me real money, so the rule is 1 credit per fresh successful lookup. But three kinds of rows are free:

Cached — I cache every result for 30 days. A repeat lookup of the same number costs me nothing, so it costs the user nothing.