The feelslike field isn’t always what you think it is
WeatherAPI’s feelslike_c and feelslike_f fields are a blended output — wind chill at lower temperatures, heat index at higher ones, with a crossover somewhere in the middle. That’s a reasonable number for a display widget. But if you’re building something that actually depends on thermal comfort — an outdoor work scheduler, a fitness app, an events platform deciding whether to surface a weather warning — a single blended field hides the mechanism, and the mechanism matters.
Dew point is what you actually want when the question is “how muggy does this feel.” Relative humidity alone doesn’t answer that well. 80% humidity at 10°C feels fine; 80% humidity at 32°C is oppressive. Dew point collapses that into one number: it tells you the absolute moisture content in the air, independent of temperature. Above roughly 16°C dew point, most people start to notice the humidity. Above 21°C, physical exertion becomes genuinely difficult. Above 24°C, sustained outdoor activity is dangerous by most physiological measures — roughly where NOAA’s heat index scale enters “extreme caution” territory even at moderate air temperatures.
What the API actually returns
A current conditions response from WeatherAPI includes temp_c, humidity (relative, as a percentage), dewpoint_c, feelslike_c, and heatindex_c. Those last two are separate fields, which is easy to miss. heatindex_c is calculated using the Rothfusz regression formula from NWS, and it’s only meaningful above about 27°C with humidity above 40%. Below that threshold it produces unreliable numbers — don’t read it blindly and display it.
The forecast endpoint also returns avghumidity per day and hourly dewpoint_c values inside forecastday[].hour[]. Hourly dew point is where most of the actionable signal lives for scheduling use cases.
A concrete example: outdoor work safety flagging
Say you’re building a scheduling tool for a construction company that wants to know which hours tomorrow are risky for outdoor crews. “High temperature” is too crude — a dry 36°C in Phoenix is bearable with water and shade in a way that a humid 32°C in Houston is not. The function below pulls the hourly forecast and returns flagged hours based on dew point thresholds rather than temperature alone:
import requests
API_KEY = "your_api_key"
LOCATION = "Houston"
def get_risk_hours(location, date_str):
url = f"http://api.weatherapi.com/v1/forecast.json"
params = {
"key": API_KEY,
"q": location,
"days": 2,
"aqi": "no",
"alerts": "no"
}
resp = requests.get(url, params=params).json()
target_day = None
for day in resp["forecast"]["forecastday"]:
if day["date"] == date_str:
target_day = day
break
if not target_day:
return []
flagged = []
for hour in target_day["hour"]:
dp = hour["dewpoint_c"]
temp = hour["temp_c"]
time_label = hour["time"]
# Only flag daytime working hours
hour_of_day = int(time_label.split(" ")[1].split(":")[0])
if hour_of_day < 6 or hour_of_day > 18:
continue
risk = None
if dp >= 24:
risk = "HIGH"
elif dp >= 21:
risk = "MODERATE"
elif dp >= 18 and temp >= 30:
risk = "ELEVATED"
if risk:
flagged.append({
"time": time_label,
"temp_c": temp,
"dewpoint_c": dp,
"risk": risk
})
return flagged
results = get_risk_hours(LOCATION, "2025-08-15")
for r in results:
print(r)
The thresholds here aren’t arbitrary. The 21°C and 24°C cutoffs correspond to the “uncomfortable” and “oppressive” dew point bands used in US operational meteorology.
Why relative humidity alone leads you wrong
A common approach is to flag hours where humidity > 80%. The problem: on a cool morning at 14°C you can easily see 85% relative humidity with a dew point around 11°C — mildly damp, physiologically unremarkable. Meanwhile a 55% reading at 34°C puts the dew point around 23°C, firmly oppressive. Flag the first, miss the second, and you’ve inverted what you’re trying to catch.
If you’re working with an endpoint or an older integration that doesn’t return dew point directly, you can approximate it with the Magnus formula:
import math
def approx_dewpoint(temp_c, humidity_pct):
# Magnus formula approximation, valid roughly -40°C to 60°C
a = 17.27
b = 237.7
alpha = ((a * temp_c) / (b + temp_c)) + math.log(humidity_pct / 100.0)
return (b * alpha) / (a - alpha)
This is an approximation, not a measurement. For non-safety-critical display purposes it’s fine. For anything feeding into operational decisions, use the API’s native dewpoint_c field — it’s derived from actual station data, not back-calculated from rounded humidity percentages, and that difference shows up at the margins.
Heat index: when to use it, when to ignore it
heatindex_c is worth using directly when temp is above 27°C and humidity is above 40% — that’s the regime the Rothfusz equation was calibrated for. The NWS notes the formula can run several degrees off when applied outside that range, so there’s a real cost to displaying it unconditionally.
One thing worth knowing: the heat index formula was developed for shade conditions. It assumes the person isn’t in direct sunlight. Sun exposure can add 8–15°C to the effective felt temperature, which is why some occupational health standards use WBGT (Wet Bulb Globe Temperature) for outdoor worker safety. WBGT requires solar radiation data that most weather APIs don’t currently expose in a usable form, so it’s not something you can easily calculate from a standard forecast response.
A practical display heuristic
For a general-audience app: show heatindex_c if temp is at or above 27°C and humidity is at or above 40%, show feelslike_c otherwise (it handles wind chill at low temps and mid-range wind effect in between). For anything with a safety or scheduling angle, build the logic on dewpoint_c directly — it doesn’t carry the regime constraints that heat index does, and it’s a direct physical measurement rather than a comfort approximation.
The honest caveat: dew point from a weather station carries the same representativeness limitations as any surface observation. A reading from a station a few kilometers away across different terrain isn’t guaranteed to reflect conditions at your exact location — this matters most near water and in hilly areas. For most urban and suburban scheduling use cases it’s close enough. For high-stakes applications, validate against local observations where you can.
If you’re currently surfacing only feelslike_c, pull the hourly forecast response for a humid summer day and look at the dew point trajectory hour by hour. The hours your users most need flagged — the ones where heat index spikes — are usually exactly where a blended “feels like” number tells them the least about why it’s uncomfortable. That’s the gap worth closing first.