Every contact-data API we looked at before building Fyonta priced by credit. It's the default for the category, and there's a real reason for it: it lets a vendor charge more for expensive operations (phone lookups, which cost real money upstream) without raising the price of cheap ones. That's a legitimate reason. We still didn't want to build it that way.
The problem we kept running into
Credit pricing pushes a spreadsheet problem onto the customer. Before you can answer "is this plan enough for us," you have to map your actual workflow to per-operation credit costs, estimate your monthly mix, and hope your usage doesn't drift. We'd rather answer "how much will this cost me" with one number.
The tradeoff, honestly
Flat-rate pricing means we're absorbing the variance instead of passing it through per-lookup. In exchange, we cap throughput with a request-rate limit instead of a spending limit. If your workload is bursty and unpredictable, that's a real constraint — you can't stockpile unused capacity from a quiet month to spend during a busy one. If your usage is steady, it's a straightforward trade: predictable bill, no credit math.
Who this is a worse fit for
If you make a handful of lookups a month, a small credit pack from a competitor will likely cost less than either of our plans. We're not trying to be the cheapest option at very low volume — we're optimizing for teams who'd rather not think about their data bill every month.