Why I stopped using OpenWeatherMap for travel apps

For years, OpenWeatherMap was the first thing I reached for when a travel project needed a forecast. Sign up, grab a key, call an endpoint, done. Half the weather widgets on the internet were built that way, and plenty still are.

I don’t do that any more. Not because OpenWeather is bad (it isn’t, and I’ll be specific about where it’s better), but because the shape of its product stopped matching the shape of a travel app. Here’s the argument.

The free tier isn’t the problem

Let’s be fair first, because a lot of “I switched” posts aren’t. OpenWeather’s pricing page lists a free plan with 60 calls a minute and 1,000,000 calls a month, covering current weather, a 5-day forecast in 3-hour steps, air pollution, weather map layers and geocoding. Its detailed pricing page says the free plan needs no payment details and allows commercial use, with visible attribution to OpenWeather.

That’s generous. For a hobby project, a single-city dashboard or a commercial site that can live with 3-hour forecast steps, it’s hard to argue with.

So when I say I stopped using it, I’m not saying it’s stingy. I’m saying the costs showed up somewhere other than the invoice.

An API key is a liability in a travel app

Travel apps are unusually likely to call a weather API from the client. You’re on a route page for Lagos to London, you want the weather at both ends, and the laziest implementation fetches it from the browser. That means the key ships to every visitor.

Once that key is public, three things follow:

1. Your rate limit becomes everyone’s rate limit. The free plan’s 60 calls a minute is per key, not per user. OpenWeather’s FAQ says exceeding it returns a 429 error. A modest traffic spike from a link on a forum and every visitor’s weather widget breaks at once.
2. Anyone can borrow your key. Scrapers find keys in page source. You can rotate it, but a brand-new key isn’t instant: the FAQ says a key is activated automatically “up to 2 hours after your successful registration.”
3. You end up building a proxy anyway, to hide the key and enforce your own limits. At which point the key’s main job is to be a thing you protect.

None of this is unique to OpenWeather. Any keyed API has the same shape. But weather is a case where the key buys you less than you’d think, because the underlying forecast is the same for every user looking at London this hour.

The product keeps moving under you

The forecast data I care about for travel (hourly temperature and rain probability for the next few days, daily highs and lows) sits in OpenWeather’s One Call product, not the classic free endpoints. One Call is its own subscription. The One Call API 3.0 page describes a separate “One Call by Call” subscription with 1,000 free calls a day and pay-per-call after that.

And now there’s a One Call 4.0. OpenWeather’s migration guide says 3.0 remains available and isn’t being switched off as part of the release, which is decent of them. But 4.0 is a different shape: modular endpoints instead of one combined response, pagination for large requests, and, per the same guide, each paginated request billed as its own call.

Each of these changes is defensible on its own. Together they add up to maintenance. For a travel site with thousands of airport and city pages, “which One Call version, which subscription, how is pagination billed” is not a question I want to re-answer every year or two.

Provenance matters when you show forecasts to travellers

When someone is deciding whether to pack a raincoat for Accra or Edinburgh, I’d like to be able to tell them where the forecast came from. Open-Meteo is unusually explicit about this. Its licence page lists the national and international weather services it draws on, including Deutscher Wetterdienst, ECMWF, NOAA, Météo-France, the Japan Meteorological Agency, the UK Met Office, MeteoSwiss and others, plus Copernicus data.

The licensing is also simple to reason about: API data is under CC BY 4.0, and the attribution is a link reading “Weather data by Open-Meteo.com”. OpenWeather also requires attribution and publishes its own licence terms; both are workable. But I find “here is the licence, here are the sources” easier to explain on a page that’s meant to be trustworthy travel information.

What I use instead

Open-Meteo, behind a small caching worker. Here’s how the request flow changed.

The key idea: weather for a place changes on the order of an hour, not a page view. So the browser asks my worker for “weather near 51.47, −0.45”. The worker rounds the coordinates, checks its cache, and only on a miss calls Open-Meteo, storing the response for a sensible window. A thousand visitors to the Heathrow page in an hour become one upstream request. That pattern works with any provider, including OpenWeather, but it’s what makes a keyless API pleasant rather than risky.

Two details made the cache work well in practice. Rounding coordinates to one or two decimal places means nearby lookups (the terminal, the car park, the airport’s official coordinates) share one cache entry. And setting the cache lifetime to match the forecast’s own update rhythm, rather than a round number, avoids serving stale data right after a new model run lands.

What Open-Meteo gets right for this use:

• No key for the free tier. Its terms say the free API needs no API key.
• Documented limits. The same terms list 600 calls a minute, 5,000 an hour, 10,000 a day and 300,000 a month on the free tier. With a cache in front, a travel site stays well inside those.
• Hourly and daily data in one request, with the variables you choose in the query string. The docs page builds the URL for you.

And the part you must not skip: Open-Meteo’s free API is for non-commercial use only. Its terms say so explicitly, and give websites with advertising and commercial products as examples that need a paid plan. If your travel site earns money (affiliate links count, in my reading), budget for an Open-Meteo subscription, just as you would for OpenWeather’s paid tiers. Here, OpenWeather’s free plan is actually the more permissive of the two, and that’s a genuine point in its favour.

So this isn’t “free versus paid.” It’s that, for a travel product, I’d rather pay for a simple, well-sourced, keyless-by-design API sitting behind my own cache than manage keys, subscriptions and version migrations for data that’s identical for every visitor. If your needs are different, such as a small commercial widget, minute-by-minute precipitation, or historical data, OpenWeather may well still be the better fit. Pick on architecture, not on who has the bigger free number.