I cannot fathom why such a highly-sought wishlist item didn’t get addressed by the launch of '24 - not even a “not planned”, not a partial address like
which would have done so much for the 3rd party add-ons while being far less resource-intensive than the points above. And now, even though this is tagged as a FS24 wishlist item, it’s missing from the “Lifetime” list.
I would resubmit it, even just in that limited fashion of METARs only, but it’s not allowed anymore:
A METAR by lat/lon and by facility ident API has been in the sim for several years already. It is available on the JS listener JS_LISTENER_FACILITY using the GET_METAR_BY_LATLON and GET_METAR_BY_IDENT calls, and is also available via the MSFS Avionics Framework SDK.
The sim NXi has displayed this information for a very long time, and WASM gauges can have this info communicated to them via the comms bus API is they want to get it.
this has been asked for since MSFS 2020 first launched and at this point it’s clear that it’s simply not going to happen. my guess? opening weather up to an API may violate Microsoft’s contract with MeteoBlue, who provide the real-time weather feed.
It’s not going to happen because the weather system in MSFS is completely different than previous sims. FSX and P3D had a feature known as “themes” which developers such as ActiveSky could use to place specific clouds at specific locations and heights, both surface and aloft. That feature simply does not exist in MSFS. Whats more, in previous sims, clouds were generated from pre-existing 2D textures, while in MSFS they are dynamically generated from data contained in the gridded model, supplemented by r/t satellite imagery.
MSFS was designed to work directly with the contents of a standard global gridded weather model, which has multiple vertical layers containing multiple types of data per layer. If they were to “open up” an API, any weather injector would have to provide the exact same type of data, and in the same format, that MeteoBlue already provides. There would be nothing to be gained by that.
The only possibility would be if an injector used an alternate gridded model such as the GFS, but that probably would make little difference in the overall weather depiction.
No 3rd party developer has the means to generate their own gridded model to replace the one supplied by MeteoBlue. Such models require many hours to create, can only be generated on a supercomputer, and using input data that by and large is not available to the general public. Such models would have to come from a professional weather data provider like MeteoBlue, or government sources. It is possible to access the model data from the US GFS model for free from the NOAA NCEPS server, but it would require a lot of post-processing to put it into a form that MSFS could use.
I’m not in the least concerned about the lack of a weather injection API.
however, all the premium third party aircraft developers have been asking (for years now) for an API that will allow them to build a proper 3d weather radar into their simuation. the “weather radar” feed provided by MSFS for use by add-ons is simply a canned top-down 2D bitmap of a horizontal slice through the weather at an undisclosed altitude. it doesn’t change, no matter the flight level. it can’t be tilted up or down, which is how all modern weather radars are actually used: pilots need to look at weather returns from above and below their flightpath when they are climbing or descending, or picking a clear altitude to avoid turbulence. a proper weather API would allow developers to display real-time 3D weather radar returns based on the actual weather around the plane.
the lack of such an API is why the weather radar on the FlyByWire, Fenix and PMDG and (in think) the IniBuilds planes are all INOP. the developers have made a conscious decision not to use the Microsoft-provided 2d slice because it’s unrealistic in a study-level environment. better to have no weather radar than a fake approximation of one.
briefly explained by actual Boeing 737/Airbus A330 pilot:
when asked why no weather API was provided, representatives of the major study-level airline developers were told that it would violate Microsoft’s contract with MeteoBlue.
Perhaps a simple way is to make a new contract. Weather display is one of major point on heavy (ATC ALSO !). It is probably most important to have them in a flight simulator than a flower and grass on the ground 
(not a critic, just a suggestion)
i think the issue is that Microsoft has access to MeteoBlue’s API for a considerable fee, and they don’t pass on that low-level access to third parties. it’s expressed in the game by the volumetric cloud layers, and by the uneditable 2d weather radar bitmap that’s supplied to aircraft radar displays. that’s it. there’s no way to leverage it to scrape additional data.
opening up a low-level weather API (which would need to have access to cloud, wind, and QNA info for the entire world from ground level to high altittude, at the minimum) would amount to granting third parties basically free access to a large chunk of MeteoBlue’s proprietary weather database. someone could potentially write an external program which accesses such an API (masquerading as an MSFS addon) to make a payware windy.com-like phone app, for instance, without paying MeteoBlue a cent.
i imagine that’s the root issue here.
I’m crossing my finger. We are talking about Microsoft, the worldwide software leader. It is not a little firm 
One of the most voted and responded to topics, and Asobo is not budging. Let ActiveSky take over!