All Blogs
Google Health API skin temperature: raw readings and nightly baselines
Google Health API v4beta adds minute-level skin temperature for Pixel Watch 4 and 5. Compare raw sensor readings, nightly baselines and developer access.
There is a pleasantly nerdy detail in Google's new skin-temperature documentation: the watch's own temperature gets a seat at the table.
That is a good place to start. A wearable sits between a person and their surroundings. Before giving a number an impressive label, it helps to know which of those things the sensor measured.
On October 1, 2026, Google added a v4beta channel and the skin-temperature-sensors data type to the Google Health API. The channel is a preview for partner testing ahead of promotion to stable v4. Google's current access notice also says new projects are not being onboarded. Availability in the reference documentation therefore deserves a separate check against your project's actual access. Google release notes.
Google Health API now offers two ways to read wrist temperature: minute-level sensor measurements through skin-temperature-sensors, and nightly summaries through daily-sleep-temperature-derivations. The new raw feed supports Pixel Watch 4 and Pixel Watch 5. The nightly feed covers a broader set of temperature-equipped Pixel Watch and Fitbit devices. The choice determines how much processing your application needs to do. Google's device and data-type guide.
Raw skin temperature and nightly derivations have different jobs
Each minute in the raw feed contains paired measurements, labelled SKIN_TEMPERATURE_SENSOR and INTERNAL_DEVICE_TEMPERATURE_SENSOR. The nightly results arrive already processed, using thermal modelling and sleep segmentation. Averaging the raw readings will not reproduce them. That distinction is useful: the API gives you a choice of processing level, rather than two interchangeable resolutions of the same metric. Skin temperature guide.
We like the nightly view as a starting point for a product. A chart showing deviation from someone's usual range can be understood without a lecture on thermal hardware. Google supplies both nightlyTemperatureCelsius and baselineTemperatureCelsius; subtracting the second from the first gives the nightly deviation. The raw feed is more interesting when you have a concrete analytical question and the resources to validate your own processing.
More samples can be exciting. They also give you more opportunities to be confidently wrong at higher resolution.
Keep the sensor attached to the number
The same guide distinguishes peripheral skin temperature from core body temperature and explicitly excludes fever detection and clinical diagnostics. It tells developers working with granular telemetry to handle noise and ambient conditions, and to keep the two sensor types distinct. Google's interpretation guidance.
That should shape your data model before it shapes the chart. Retain the device, sensor type, timestamp, unit, and processing method with every measurement. Once those details have been collapsed into a generic temperature field, recovering the meaning later becomes an archaeological project.
The same applies to missing readings. A product should distinguish an unsupported device from a supported device with no recent data. An empty graph that invites the user to reconnect forever is a remarkably effective way to make healthy people feel that something is wrong.
Give a change some context
For a first feature, show temperature deviation alongside the relevant sleep period, with a plain explanation of the baseline. Let a user inspect the change over time and add context if they want to. Avoid turning a single unusual night into an automatic explanation of what happened to their body.
For a research-oriented product, granular readings could support experiments around within-night patterns. The release provides the measurements; the team still has to establish that its processing answers the intended question before shipping an interpretation.
There is useful engineering freedom here. You can work with an existing derivation or investigate a more detailed signal. The freedom comes with an obligation to say which one you chose.
For teams using a data integration layer, check the mapping too: a provider adding a data type does not establish that every downstream platform already exposes it. Preserve the distinction between the original measurement and your own derived result wherever the data travels. Our Google Health API guide covers the broader endpoint architecture; check Google's current release notes for access and data-type availability. Nothing in this release alone confirms that the new beta feed is exposed through Terra.
The detail worth carrying into the product is the one that made this release interesting in the first place. The sensor has a location, the watch has an environment, and the user has a history. A temperature chart becomes useful when all three survive the journey.
