Floors Climbed and Elevation API: Floors, Elevation Gain and Altitude

Vertical movement is two metrics that platforms bundle differently. A floor count is a step-counter idea, derived from climbing; an elevation figure is a distance. Some platforms have both, some have one, and the two that look most alike, Google's altitude and Health Connect's elevation gained, are not what their names suggest.

Floors: one idea, three number types#

Read from Google's documentation on 2026-10-17 and 2026-10-03, Apple's on 2026-10-02 and Google's Health Services reference on 2026-10-04.

The descriptions do not even agree on what is counted. Apple's type "measures the number flights of stairs that the user has climbed." Health Connect's record "Captures the number of floors climbed by the user since the last reading." Google's cloud type is "Gained elevation measured in floors over the time interval," which makes a floor a unit of height rather than a staircase. Wear OS says: "Number of floors climbed since the last update. Note that partial floors are supported, so this is represented as a Double." An integer on Google's side and a Double on the watch means a total moved between them can lose its fractions.

Google's floors cannot be listed#

Google's data-types table lists reconcile, rollup and dailyRollup for floors, and no list. You cannot page through the raw data points; you ask for a rollup over a window and read countSum. The table also links the type to the rollup's reference anchor rather than the data point's, which the Google Health API floors page shows as a flag. The type has a 1-minute storage resolution, webhook support and true-zeros support, and Google maps the Fitbit Web API's floors data to it.

Elevation: a signed gain, a split, or nothing#

Three differences matter in code.

Google's altitude is not an altitude. Its own description says it captures gains, "and not level above sea." The name came from somewhere else; the field is gainMillimeters, an integer, summed by the rollup into gainMillimetersSum. Google maps the Fitbit Web API's elevation data to it.

Gain and loss are one signed value on two platforms and two unsigned values on the third. Health Connect's and Google's documented ranges both run below zero, while Wear OS keeps losses out of ELEVATION_GAIN and gains out of ELEVATION_LOSS. Neither Google page says what a negative gain represents, so if you move Wear OS readings into Health Connect, decide how losses are written and say so; do not assume a reader on the other side expects them.

Absolute elevation needs location permission. Google's Health Services permissions table puts ABSOLUTE_ELEVATION with LOCATION under ACCESS_FINE_LOCATION, while floors and elevation gain and loss sit under ACTIVITY_RECOGNITION. Asking for absolute elevation is asking for the user's location.

HealthKit keeps elevation in metadata#

There is no elevation identifier in HealthKit. Apple documents two workout keys instead, HKMetadataKeyElevationAscended and HKMetadataKeyElevationDescended, "the cumulative elevation ascended during a workout" and its descending counterpart. Apple says to set them "on a workout, workout segment, or a quantity sample that represents distance," with a length-unit quantity, and that HealthKit assigns them itself to the segments it creates for downhill skiing and snowboarding workouts on Apple Watch Series 3. To read elevation on iOS you read workouts and their metadata, not a sample type; the Google Health API's exercise summary likewise carries an elevationGainMillimeters total per exercise, separate from the altitude type.

Traps#

• Rolling up is the only read for Google floors. Code that lists every data type in a loop will fail on floors; route it to rollUp.
• Fractions in, integers out. Wear OS and Health Connect floors are Doubles, Google's are integers. Decide where you round.
• Signed versus split elevation. Sum Health Connect gains naively and any negative values cancel climbing; sum Wear OS gain and loss naively and you get total vertical travel, not net change.
• Permissions differ by meaning. Elevation gain is an activity permission on Wear OS; absolute elevation is a location permission.
• No HealthKit type to request. An iOS feature built around elevation gain is a workout feature; request workout read access and read the metadata.

Before you ship#

Re-read the type pages linked here before each release; they regenerate from Google's and Apple's documentation. Route Google floors through rollups, keep floors as a Double in your own store, carry gain and loss as separate signed or unsigned columns according to the source, and never present Google's altitude as height above sea level.