The field isn’t there — but the data to derive it is
If you’re building for aviation, mountain operations, ski forecasting, or icing-risk detection, you’ve probably gone looking for a freezing_level_m or isotherm_0c field in a weather API response and found nothing. WeatherAPI.com doesn’t expose freezing level altitude as a direct field. Neither do most REST-style weather APIs. The reason is straightforward: it’s a derived quantity, not an observed one — and the raw ingredients to compute it yourself are all there in the response.
This post covers how to derive freezing level from the fields WeatherAPI does return, where the method breaks down, and when to be skeptical of your own output.
What freezing level actually is
Freezing level (or the zero-degree isotherm) is the altitude at which ambient air temperature reaches 0°C. Below it, precipitation is liquid. Above it, it’s ice. For aviation, the freezing level marks the zone where structural icing becomes a serious concern — particularly in clouds, where supercooled water droplets exist and freeze on contact with an airframe. For ski resorts, it determines whether snowfall at summit elevation arrives as snow or as sleet.
NOAA’s Rapid Refresh (RAP) and HRRR models carry 0°C isotherm fields in their GRIB2 output. ECMWF’s IFS exposes it as a pressure-level variable. The WMO and NWS publish freezing level forecasts derived from the same NWP model output. The number exists. It just rarely makes it into simplified API responses.
The standard atmospheric lapse rate approach
The environmental lapse rate in a standard atmosphere is 6.5°C per 1,000 meters — the ISA (International Standard Atmosphere) definition. It’s good enough as a starting estimate when you don’t have full upper-air sounding data.
Given a surface temperature and a surface elevation, the estimated freezing level altitude is:
freezing_level_m = surface_elevation_m + (temp_c / 6.5) * 1000Surface at 200m, temperature 8°C: freezing level is approximately 200 + (8 / 6.5) * 1000 = 1,431m above sea level.
WeatherAPI returns temp_c in both current and hourly forecast responses. Elevation is available via the location object (location.elevation_m — the elevation at the requested coordinate, not sea level).
Python implementation
import requests
API_KEY = "your_key"
q = "Fort_William,UK"
resp = requests.get(
"https://api.weatherapi.com/v1/forecast.json",
params={"key": API_KEY, "q": q, "days": 1, "aqi": "no", "alerts": "no"}
)
data = resp.json()
surface_elevation = data["location"]["elevation_m"] # metres ASL
for hour in data["forecast"]["forecastday"][0]["hour"]:
temp_c = hour["temp_c"]
time = hour["time"]
if temp_c <= 0:
# Surface is already at or below freezing — freezing level is at or below surface
fl = surface_elevation
else:
fl = surface_elevation + (temp_c / 6.5) * 1000
print(f"{time} surface: {surface_elevation}m temp: {temp_c}°C est. FL: {round(fl)}m ASL")
Fort William is a useful test case here. It sits at low elevation at the base of Ben Nevis, and icing conditions on the mountain during winter are a genuine safety concern for climbers. The surface temp in town and the freezing level on the summit are often separated by several hundred meters of altitude — enough that the difference is operationally meaningful, not just academic.
Where this breaks down
The standard lapse rate is an average. The actual environmental lapse rate varies with time of day, season, air mass type, and stability. There are three situations where the estimate above will be materially wrong.
Temperature inversions
An inversion is when temperature increases with altitude — the opposite of the standard assumption. This happens most often overnight in calm conditions and in valley fog. If there's an inversion below the freezing level, the formula will overestimate freezing level height: the surface temperature reads warmer than the column above it, so you project the 0°C crossing higher than it actually is. There's no direct inversion flag in a REST weather API response. A small temperature-dewpoint spread (under roughly 2°C) combined with calm winds is a soft signal of a stable, potentially inverted airmass — worth treating the estimate with extra skepticism when you see it.
Precipitation evaporative cooling
When precipitation falls through a dry layer, evaporation cools the air below the standard lapse rate assumption. This can drag the freezing level downward toward the surface, sometimes significantly. It's the mechanism behind freezing rain events that catch people off guard when surface temperature reads 3–4°C — the precipitation cools through 0°C before it reaches the ground. There's no reliable way to detect this from surface observations alone.
Elevated terrain and high-base starting points
The formula assumes the queried surface is the base of the temperature gradient. If you query a valley coordinate but care about freezing level on a nearby ridge, apply the correction from the ridge elevation — not the valley floor. Use a second API call with the ridge coordinate rather than trying to arithmetic your way there from the valley result.
Improving the estimate with dew point
A slightly more robust version uses surface dew point to add context. The dew point lapse rate is much slower than the temperature lapse rate — roughly 1.8°C per 1,000m versus 6.5°C. The level where the temperature and dew point profiles meet is the lifting condensation level (LCL), which approximates cloud base. If the LCL sits below your estimated freezing level, you're likely dealing with cloud through that layer and a higher probability of supercooled water content — which is what makes icing risk concrete rather than theoretical.
WeatherAPI returns dewpoint_c in the hourly forecast. You can estimate LCL height like this:
# Estimate LCL (cloud base) height above surface
# Rule of thumb: LCL ≈ (temp_c - dewpoint_c) / 8 * 1000 metres
temp_c = hour["temp_c"]
dewpoint_c = hour["dewpoint_c"]
spread = temp_c - dewpoint_c
lcl_height_m = (spread / 8) * 1000 # metres above surface
# If LCL is below freezing level, icing-risk layer likely exists
if lcl_height_m < (fl - surface_elevation):
print("Cloud layer likely extends through freezing level — elevated icing risk")
This isn't a substitute for actual pilot reports (PIREPs) or model icing severity products. But it's a defensible first-pass flag for an application that doesn't have access to those sources.
Using hourly data to track freezing level through the day
The forecast endpoint returns 24 hourly slices per day. Tracking temp_c and the derived freezing level across those hours gives you a usable diurnal profile — freezing level typically rises through the afternoon as surface temperatures peak, then descends overnight. For a ski resort dashboard or a mountain hiking app, flagging the hours where freezing level drops below summit elevation is a directly actionable output.
With a 3-day forecast you get 72 hourly slices. Enough to show a credible trend. Past roughly 36 hours, NWP forecast skill on temperature degrades meaningfully — especially in complex terrain — so treat anything beyond that window as directional, not precise.
What model output would actually give you
Our GRIB2 ingestion pipeline processes HRRR, NAM, GFS, and ECMWF output. HRRR, on its 3km grid, carries pressure-level temperature fields that let you track the 0°C isotherm directly through the atmospheric column — no lapse-rate approximation required. NAM and GFS do the same at coarser resolution. The reason this doesn't surface in the API as a clean freezing_level_m field is partly a schema decision and partly because the surface-field derivation is close enough for most use cases. But close enough has real limits, and those limits are worth knowing before you build something that depends on the number.
If your use case genuinely requires accurate freezing level — flight planning, avalanche forecasting, anything where the error margin matters operationally — look at whether pulling raw GRIB2 data from NOAA's NOMADS server fits your architecture. For most application developers, the approach above is a reasonable middle ground, as long as the output is flagged as approximate and the inversion and precipitation-cooling edge cases get at least a soft warning to users.
One thing worth being direct about: don't silently return a precise-looking altitude and label it freezing level. Display it as an estimate, show the derivation method if you can. Users who actually need this number for safety-relevant decisions will know the difference — and they'll trust your tool less once they figure out a lapse-rate approximation is being served with false precision. Flag it upfront and that problem goes away entirely.