Why PostalDataPI Bills the Way It Does

PostalDataPI charges $0.000028 per query.

Not $0.000028 per query in our entry tier, with a different rate after some volume threshold. Not $0.000028 per query for the first 100,000, then a higher or lower rate. Not $0.000028 per query if you sign an annual contract. Just $0.000028 per query. Single price, every query, every country, every customer.

We are sometimes asked what tier a customer should pick, what the volume discount looks like, what the minimum commit is. The honest answer to all three is: there isn't one. New accounts get 1,000 free queries on signup. After that, every query is $0.000028, deducted from a balance you top up when you want to (minimum $5). No subscription. No expiring credit. No renewal call.

This post is about why. Not "why we are cheaper" — that is a separate conversation, and we have a pricing comparison page for the reader who wants the data. This is about the structure of the bill itself, and why we decided early on to make it look the way it does.

What we wanted to avoid

Most postal code APIs and most geocoding APIs use a tier structure: free up to N queries per month, then a monthly subscription, with the per-query rate decreasing as you climb tiers. The structure looks reasonable on a pricing page. The reality of buying it is different.

What it actually feels like to be a buyer in that model:

• You start small, on the free tier. You build something. It works.
• Your volume grows. You cross the free threshold one Tuesday.
• You upgrade to the entry paid tier. You are now paying a multiple of what your volume is worth, because the entry tier overshoots your usage.
• Your volume keeps growing. You cross the next threshold. You upgrade. The per-query rate drops, but the monthly bill does not — because the new tier overshoots the new volume.
• At some point you start paying enough that the vendor's sales team gets in touch. There is a custom contract available. There are also minimum commits. The advertised per-query rate at the top of the pricing page is now an aspiration, not a price you can buy.
• If you are smaller than that, the per-query rate you actually pay is several multiples higher than what an enterprise customer pays for the same product, sometimes by an order of magnitude.

That structure is built around extracting more revenue from the buyers who have the least leverage. It is the SaaS equivalent of paying more per pound for groceries because you only buy a small bag at a time. It is normal. It is also, when you stop and look at it, just a little bit perverse.

What we wanted instead

We wanted the pricing to be the same shape as the cost of serving the request. The cost of serving one PostalDataPI query is the same as serving the millionth: a single in-memory lookup, microseconds of compute, a JSON response over an existing connection. There is no operational reason it should cost more for the small customer than the large one.

So we decided early — before we shipped, before we had a single paying user — that we would charge one flat per-query rate at every volume. The rate we picked, $0.000028, was set to give us comfortable margins at any reasonable load. We have not changed it. We currently have no plans to change it. If we ever do change it, it will be a single rate that applies to everyone equally, and we will tell every existing customer why before it takes effect.

That decision rules out a few things by construction:

• No tiers. A flat rate has no tiers. There is nothing to upgrade to.
• No volume discount. Same rate for the customer who runs ten queries this month and the customer who runs ten million.
• No commitment. No minimum monthly spend, no annual contract, no auto-renewing subscription.
• No "contact sales." The rate at the top of the pricing page is the rate. There is no door behind it that opens for big customers.
• No surprise bills. Your prepaid balance can never go negative. When it runs out, queries return a 402 status, and you choose whether to top up.

Why we are unlikely to change this

A flat rate is harder to extract revenue from. We know that. The lever a tiered model gives a vendor is real — the reason most of our peers use tiers is because they extract more revenue from the same product, not because customers prefer it.

We are choosing not to pull that lever for two reasons.

The first is moral. The reason small customers in tiered models pay multiples more per query than large customers is not that the small customers cost the vendor more. It is that the small customers can be charged more without losing them. We do not want to build a business that quietly charges its smallest customers the most.

The second is strategic. PostalDataPI is a developer-tools API. Developers are unusually sensitive to "this pricing makes me feel taken advantage of." A pricing model that visibly does not extract more from low-leverage buyers is, we believe, a real and durable competitive advantage in this space, even when the per-query math at high volume converges with a competitor's discounted rate. The shape of the bill is the marketing.

What this means in practice

For most readers of this post, the practical implication is simple: you do not have to model us. You do not have to forecast which tier you will graduate into. You do not have to commit. You sign up, you get 1,000 free queries, you build whatever you build, and if the volume goes somewhere you did not expect, the math is exactly the same. Any-volume × $0.000028.

For the reader who wants the actual side-by-side numbers — what each volume costs across PostalDataPI, Zipcodebase, Google Geocoding, Smarty, and the enterprise vendors — we maintain a comparison page with verified pricing and date stamps. The page is intentionally dry. The numbers do the talking.

For the reader who is comparing us against a vendor we did not list, the principle holds. If their pricing has a tier ladder, you are paying for the ladder. PostalDataPI does not have one.

A note about this post itself

We try to write here in our actual voice, not corporate-marketing voice. We also try to be careful about what we claim and what we do not. So one thing worth being clear about: we are not arguing that flat-rate pricing is the only honest model, or that vendors who use tiers are dishonest. Plenty of good products use tiered pricing for plenty of good reasons. We just chose not to.

What we are arguing is that the bill should look like the cost of serving you, that the small customer should not subsidize the big one, and that a developer choosing an API should not have to model their future selves into a pricing ladder. So we built one that does not require that. And if we ever build a postal code API that requires the customer to negotiate, we will have failed at something we set out to do.

Sign up for PostalDataPI. 1,000 free queries. No credit card. The same flat $0.000028 per query at every volume, forever — or until we tell you differently, in writing, with notice.