When a general weather API isn't quite enough for soaring
meteoblue has a soaring API and it's good. Here is why we still run our own WRF, and when each is the right call.
meteoblue is the closest thing to a direct competitor Convek has on the API side. It is a serious weather company - Swiss, decades old, with a substantial developer business - and unlike SkySight or TopMeteo it actually exposes soaring-relevant fields through a public API. Updraft velocity (their w*), planetary boundary layer height, CAPE, a soaring index. If your question is 'can I get thermal-flavoured fields from a general weather API', meteoblue is a real answer. So when people ask me why Convek exists when meteoblue exists, it is a fair question.
The short answer is that meteoblue's soaring fields fall out of a general-purpose machine. Their forecast pipeline blends multiple global NWP models through their Learning MultiModel (mLM) post-processing, which is genuinely clever - it picks the best-performing combination of upstream models for a given location and time. But mLM is optimising for a generic 'how good is the forecast' signal across many use cases. Convek is optimising for one use case. We run our own WRF integration on GFS initial conditions, four cycles a day, downscaled to 4 km over specific soaring regions, with a physics stack chosen for daytime convective conditions in the mid-latitudes - YSU PBL, WSM3 microphysics, Noah land surface, a vertical level packing weighted toward the bottom 3 km where the thermal action lives.
That trade-off shows up in fields you can get from one but not the other. Convek publishes a glider-capped soaring height (`hglider_agl_m`), an MSL cloudbase that matters when launch elevation varies (which it does across most countries we cover), a horizontal convergence field for finding convergence lines on the synoptic-quiet days, and a single composite day rating that scores the whole sounding rather than just the surface conditions. These are not generic NWP outputs. They are derived from a model run that knew, on the way through, what they were going to be used for. A general API does not produce them because building a general API does not give you a reason to.
Then there is corridor sampling. If you are building a tool that follows a pilot along a planned XC route, you want forecast values that move with them through time - hour 1 at the first waypoint, hour 3 at the next, hour 5 at goal. Convek's corridor endpoint does that natively. meteoblue's API is point-based. You can sample points and stitch the timing yourself, but the abstraction is the difference between 'works on day one' and 'a small subproject'.
Where meteoblue wins, honestly: coverage breadth, model maturity, and the fact that one API key serves you a global weather product for many use cases beyond soaring. The pricing is also worth thinking about. meteoblue is credit-based - you prepay a pool, and each API call deducts credits depending on the field set. That works well if your call volume is bursty or unpredictable. Convek is flat monthly - £39/month on the commercial dev tier - which is simpler if you want predictable line items but more expensive if you barely query it.
If you are building a general-purpose weather feature where soaring is one of several uses for the same key, meteoblue is the obvious choice. If you are building something soaring-specific and want native RASP fields, a free tier you can actually run in production, and predictable flat pricing, that is what Convek is for. The longer side-by-side on data, pricing, and licensing lives on the comparison page.
The honest summary: meteoblue is a great general weather API with soaring fields included. We are a specialist soaring API with the fields a glider or paraglider tool actually needs. Both can be the right answer. The page above lays out which is which.