DEV Community

Cover image for What a weather API comparison table leaves out
Petrichor
Petrichor

Posted on

What a weather API comparison table leaves out

A comparison table gets a provider onto your shortlist. Something else gets it picked.

I answer the support inbox at Meteosource, a weather API, so I read most messages from people in the middle of an evaluation. Price comes up early in almost all of them. It is the easiest thing to compare, so it gets compared first.

It is rarely what settles it. Four other questions show up more often, and none of them are answered on a pricing page.

Can I test this in the next five minutes

Not features. Not accuracy. Whether a response can be on screen while the idea is still interesting.

A card form on a free tier loses at this step. So does a sales call before an API key. So does a signup flow asking for company size and use case before it gives you anything.

The message underneath all of it is the same one that kept landing in our inbox: I just want to see the JSON. That is why our free tier is 400 calls a day with no card, and it is the single change that moved trial signups the most.

What does the license actually allow

Plenty of free and cheap weather tiers are non commercial. Fine for a dashboard on your own wall. Not fine the moment your app has a paying user.

Anyone caught by this once now reads the terms before the docs. It takes two minutes and it saves a migration later. Worth checking on any provider you shortlist, including us.

What happens when I hit the limit

Three common answers, and they are not equally pleasant.

A hard 429 tells you immediately. Silent throttling gives you degraded data and no signal, which is the worst version because your users find out before you do. Overage billing gives you a surprise invoice after a retry loop runs over a weekend.

Predictable beats generous. A smaller cap you understand is easier to build on than a large one with fuzzy rules.

Will this pricing still work in a year

The pattern people are checking for is the cliff. A cheap starter plan, then nothing until an enterprise contract with a sales process attached.

If usage doubles, does the bill roughly double, or does it jump by a factor of ten. Anyone who has migrated off a provider mid project looks for that gap before writing a line of code.

We tried to avoid it by splitting features and call volume into separate choices, and by metering historical data per day per location instead of gating it behind a tier. It is not perfect. Our per location Renewables pricing genuinely does not suit anyone who wants to query a hundred scattered points occasionally, and a call based provider will be cheaper for that shape of usage. Different models fit different problems and pretending otherwise wastes everyone's time.

Why none of this shows up in a comparison table

Because none of it is comparable. Signup friction, license scope, limit behaviour and pricing shape are all specific to how you plan to use the thing. There is no column for them.

So they get left out, the table fills up with price and call counts, and the four questions that decide it end up as your own ten minutes of digging through docs and terms.

That cuts both ways. As a provider you cannot write your way out of any of it. They are product and terms of service decisions, sitting in public, and the only way to look better on them is to be better on them.

For anyone who has integrated a data API recently: what made you close the tab? Not the thing you complained about six months in, the thing that ruled a provider out on day one.

Top comments (0)