If you pull feelslike_c from a WeatherAPI response and display it directly, you’re probably right most of the time. But “most of the time” hides real edge cases — and if you’re building anything where thermal comfort actually matters (outdoor worker safety, HVAC control, running apps, construction scheduling), you want to know what’s being computed under the hood and where the model quietly falls apart.
It’s Not One Formula — It’s a Conditional
There isn’t a single “feels like” equation. The value that comes back is derived from one of two different physical models depending on conditions, and the handoff between them is where things get interesting.
Below roughly 10°C (50°F) with wind above a threshold, the calculation uses the Wind Chill Index developed by Osczevski and Bluestein and adopted by NOAA and the Meteorological Service of Canada around 2001. The formula is:
WCI = 13.12 + 0.6215·T − 11.37·V^0.16 + 0.3965·T·V^0.16T is air temperature in °C, V is wind speed in km/h. The exponent on wind speed is the key thing: the marginal effect of wind diminishes as speed increases. Going from 0 to 20 km/h matters a lot. Going from 60 to 80 km/h, much less.
Above roughly 27°C (80°F) with humidity high enough to be relevant, the model switches to the Heat Index — Rothfusz’s regression, a multi-term polynomial that NOAA publishes and uses operationally. It accounts for relative humidity’s effect on the body’s ability to shed heat through evaporation.
In the middle zone — neither cold enough for wind chill nor warm enough for heat index to do much — feelslike_c often just tracks the actual temperature closely, with only modest adjustment. That’s not a bug. Thermal stress genuinely is low at 15°C with light wind and moderate humidity.
Where the Cracks Are
The Wind Chill Index was designed for walking-pace wind exposure in open terrain. It assumes bare skin, face-level wind. What the API feeds it is a standard 10-meter surface wind measurement — which is the meteorological convention, not face height. That introduces a consistent offset. NOAA recommends adjusting for this in safety-critical applications; most consumer apps don’t, and for most purposes the error is small enough to ignore.
The bigger issue is solar radiation. Neither wind chill nor heat index accounts for direct sun exposure. Stand in direct August sun at 28°C with low humidity and the Heat Index might return 29°C, which sounds fine — but four hours of that and your core temperature disagrees. Apparent temperature models that do account for radiation (Steadman’s original work, or what the Australian Bureau of Meteorology publishes) produce materially different numbers in high-insolation conditions. The uv_index field is there in the response; feelslike_c doesn’t fold it in. That’s worth knowing before you build on it.
The Heat Index also has explicit domain limits: it’s not meaningful below about 27°C or at relative humidity below roughly 40%. The Rothfusz polynomial was fit to data within those bounds. Extrapolate past them and you get garbage — at 35°C and 20% humidity the formula can output values below the actual air temperature. Evaporative cooling is physically real, but the model wasn’t designed to be trusted in that regime.
What the API Response Actually Tells You
No field in the current response tells you which formula produced feelslike_c for a given observation. You have to infer it from the other values. If temp_c is below 10 and wind_kph is above roughly 5, you’re almost certainly in the wind chill branch. If temp_c is above 27 and humidity is above 40, you’re in heat index territory. Everything in between, the value isn’t doing much modeling — it’s close to the raw temperature.
This matters for validation. If you’re building a test suite against expected output, don’t expect smooth interpolation across the temperature range. Expect a conditional branch, and test the edge cases near the thresholds explicitly. A location sitting at exactly 10°C with 25 km/h wind is right on the boundary and worth checking directly.
A Concrete Example
Say you’re building an outdoor work scheduling tool. You get a forecast for Glasgow at 6°C with 35 km/h wind gusts. The Wind Chill Index puts that at approximately −1°C feels-like. Scotland in February routinely produces those inputs, and dressing for 6°C when the effective exposure is −1°C is a real safety gap for anyone working outside for a full shift.
Now the same location in late July: 22°C, 75% humidity, 8 km/h wind. Heat index doesn’t quite apply (22°C is below its reliable range), wind chill doesn’t apply, so feelslike_c comes back close to the actual temperature — maybe 21°C. But if there’s strong afternoon sun and the UV index is 5, the actual thermal load on that worker is noticeably higher than the API value reflects. For low-stakes decisions you’d never notice. For sustained outdoor exertion it could matter.
If You Need More Than feelslike_c
For applications where thermal comfort is central to the product — not just a display widget — pull the underlying components and run your own composite. You need temp_c, humidity, wind_kph, and uv_index at minimum. From those you can implement a full apparent temperature calculation, or apply WBGT (Wet Bulb Globe Temperature) approximations that account for radiation load. WBGT is what OSHA and most occupational health guidelines use for heat stress thresholds — a more defensible basis for anything safety-critical than a consumer feels-like value.
All those fields are present in a standard current conditions or forecast response. Nothing exotic needs enabling. The calculation just lives on your side rather than ours.
The Honest Limitation
Even with all those components, apparent temperature is still a modeled proxy for human thermal experience — and that varies significantly by fitness, acclimatization, clothing, and activity level. No API field captures those. What the API can do is give you accurate physical inputs so your own thermal model doesn’t fail for the wrong reasons: bad humidity, wrong wind speed, stale temperature. That’s where the accuracy work actually lives.
If you’re branching logic on feelslike_c — alerting users, restricting activities, adjusting pricing — the question worth sitting with is whether you actually know which formula produced that number for the conditions you care about most. Pull the underlying fields and check.