When you ask for the weather at your house, the temperature usually comes from a weather station somewhere nearby. Your coordinates tell the API where to look. They don't mean a thermometer took a reading at that exact spot.
That distinction is easy to lose when the entire answer is one big temperature on a screen. It matters if the station is several kilometers away, or if the latest reading is older than the person looking at it expects.
The /weather response keeps the reading and its context together. current contains the core measurements, including temperature, humidity, wind, and observed_at. station identifies the station and gives its distance from your coordinates. Additional measurements and forecasts live in paid deep when requested and available.
observed_at is the time the observation was made. It doesn't become a new reading just because your app fetched it again. If you're storing weather alongside an event, keeping that timestamp lets you distinguish when the event happened from when the nearby weather was measured.
The station distance has a similar job. station.distance is in kilometers; station.distance_mi gives the same distance in miles. If you're displaying a reading in Fahrenheit, the distance label can use miles too. Keep the unit beside the number so a bare "12" doesn't have to explain itself.
Your application can show the station name, include an "observed at" label, or decide that a distant reading isn't suitable for the feature you're building. If no station resolved, station is null. An unreported measurement can also be null even when a station is present. Show that measurement as unavailable rather than converting a missing temperature into zero degrees.
Forecasts sit separately inside deep, when requested and available. That keeps a measured temperature and a predicted temperature from looking interchangeable as the response grows. The Weather reference lists the observation fields, units, and optional forecast detail.