All posts
Essays·5 min read

What 'Windy has an API' actually means

Windy is the most-recognised weather brand in aviation, and yes it has a developer API. Here is what that API actually returns - and the bit of their pricing page worth knowing about.

Every time I tell a pilot I run a soaring weather API, someone replies 'doesn't Windy have one of those?'. The honest answer is yes and no - and the gap between the two is most of why Convek exists. This post is a walk through what 'Windy has an API' actually means in practice.

Windy itself is a visualisation product. The maps, the layers, the time slider, the model picker - that is the consumer face. Underneath, Windy does not run its own weather model. It re-serves multiple global and regional NWP models (GFS, ICON-EU, AROME, NAM, GFS Wave, CAMS) on top of a very polished UI. The Point Forecast API is the developer entrypoint to those underlying models. Hit it with a lat/lon and a model name, and you get raw forecast values back as JSON - temperature, wind, precipitation, pressure, humidity, the usual NWP variables at the usual pressure levels.

That is the first useful clarification. The Windy API does not produce soaring-derived fields. CAPE is there (it is a standard NWP stability index), but no wstar, no PBL height as a published parameter, no cloudbase derivation, no convergence diagnostic, no day rating. None of that is a criticism of Windy - they are a global multi-model proxy, and the fact that you can hit one API and pull AROME over the Alps and NAM over North America in the same request shape is a real product. It just is not a soaring API. It is a raw-NWP API with a great brand and a great map UI.

The bit of the pricing page worth pointing out: the Testing tier is free and capped at 500 requests per day, which sounds reasonable until you read the next line of their docs, which is that the Testing tier returns 'randomly shuffled and slightly modified' data and is explicitly not for production. That is a perfectly defensible policy on their end - it stops people running production apps on a free tier - but it is worth knowing before you start building, because it means there is no 'kick the tyres in real conditions' option. You build against fake data, then you commit to the Professional tier at €990/year flat for 10,000 requests/day to see real numbers. There is no middle.

What Windy is excellent at: brand recognition with pilots (which matters more than you might think when you are pitching a tool), a polished consumer product that 'just works', and broad multi-model NWP access through a clean API. If you are building a general-purpose aviation weather tool that needs raw GFS or AROME at a point, anywhere on the globe, with a model picker, Windy is hard to beat.

What it is not: a soaring data layer. The fields a soaring app needs (wstar, BL height, BL top, soaring ceiling, MSL cloudbase, convergence) are not in the response. You can derive some of them from raw fields with enough effort - which is exactly what running your own WRF amounts to, and at that point you might as well let someone else do it. The side-by-side comparison page covers the pricing, the models, and the field-set differences in more detail.

I have nothing against Windy. I use it every flying weekend. The point of writing this post is to spare other devs the half-day where they realise 'has an API' does not necessarily mean 'has the data I need'.

Written by JadeMore in Essays