A METAR tells you what the weather is doing at the airport right now. A TAF tells you what it will do over the next day or two. Neither tells you what the wind is doing at 9,000 feet over the fix you're about to cross. That's what winds aloft forecasts are for, and if you're building anything that touches flight planning, you need a winds aloft forecast API in your stack, not a PDF chart.

Why pilots (and flight-planning software) need winds aloft data

Winds aloft forecasts drive three decisions on every cross-country flight: which altitude burns the least fuel, which route avoids a headwind that turns a 2-hour leg into 2:45, and where turbulence from a jet stream core or strong shear layer is likely to bite. A 40-knot tailwind at FL340 versus a 40-knot headwind at FL280 is a real fuel and time difference, and dispatchers and EFB apps make that call using exactly this data.

Jet contrail across a clear blue sky, the kind of high-altitude wind winds-aloft forecasts predict

In the US, this comes from NOAA's Aviation Weather Center as the FB product (often still called FD from its older designator), generated from the RAP/RUC numerical model and issued several times a day for fixed altitude levels: 3,000, 6,000, 9,000, 12,000, 18,000, 24,000, 30,000, 34,000, and 39,000 feet. Stations report a forecast for each level relevant to their location and forecast period (6, 12, or 24 hours out).

How the coded groups work

The raw FB text is dense. Each station line has a four-, six-, or in edge cases five-digit group per altitude column, in the form ddff or ddfftt:

  • dd — wind direction in tens of degrees, true (not magnetic)
  • ff — wind speed in knots
  • tt — temperature in Celsius (omitted at the 3,000-ft level and at any level within 2,500 feet of the station's elevation, since wind/temp data that close to the surface isn't forecast this way)

A few conventions trip people up:

KORD FD data, FL180 column: 290548
  29 -> direction 290°
  05 -> speed 5 kt
  48 -> temperature -48°C   (minus sign is implied above 24,000 ft)

FL090 column: 9900
  light and variable wind, under 5 kt, no temp at this level

FL340 column: 730752
  73 -> subtract 50 -> direction 230°
  107 -> speed 107 kt (100 was added because dd was coded ≥51)
  52 -> temperature -52°C

Light and variable wind (under 5 knots) is coded 9900, optionally followed by a temperature. When forecast speed is 100–199 knots, 50 is added to the direction code, so any decoded direction over 50 means you subtract 50 from dd and add 100 to ff to get the real values. Speeds at or above 200 knots are capped and shown as 99, decoded as "200 knots or greater" with direction still offset by 50. Above 24,000 feet, all temperatures are negative, so the sign is dropped from the printed group.

Pilot using a ruler on a paper aviation chart during flight planning

Reading the forecast by altitude and station

Each FB bulletin is organized as a grid: stations down the left, altitude columns across the top. To use it for flight planning you pick the station closest to (or interpolated between) your route segment, then read across to the altitude you're considering. Most pilots don't read a single station in isolation — they interpolate between two or three stations along the route and between the published altitude levels to estimate conditions at, say, 7,500 feet between two 6,000/9,000-ft columns. That manual interpolation is exactly the kind of step that's trivial for software and tedious by hand, which is the real argument for pulling this data programmatically instead of screen-scraping a text bulletin.

Getting winds aloft by API instead of parsing text

Parsing ddfftt groups, handling the 9900 light-and-variable case, and catching the 50/100/200-knot offset rules is a small but real source of bugs if you're writing a parser from scratch — and you have to keep it in sync if NOAA tweaks bulletin formatting. SkyLink API's weather endpoint returns winds aloft already decoded into direction, speed, and temperature fields per altitude level, so your app can request a station or route and get usable numbers instead of raw coded text. It's a natural pairing with our METAR/TAF guide if you're building out full pre-flight weather coverage — surface and terminal forecasts from METAR/TAF, en-route conditions from winds aloft.

If you're adding winds aloft to a flight-planning tool, EFB, or dispatch system, SkyLink API gives you a free tier of 1,000 requests/month to test against, with paid plans starting at $18.59/mo once you're ready for production traffic. It's available through the free trial — sign up, grab a key, and pull decoded winds and temperatures aloft without writing a single regex.