---
title: "Floors Climbed and Elevation API: Floors, Elevation Gain and Altitude"
canonical: "https://aifitnessapi.com/data/floors-elevation-api"
cluster: "Health Data"
primary_query: "floors climbed api"
last_reviewed: "2026-10-18"
description: "Floors and elevation on each platform: integer or fractional floors, signed gain or separate gain and loss, and HealthKit's lack of an elevation type."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Floors Climbed and Elevation API: Floors, Elevation Gain and Altitude\", AIFitnessAPI, https://aifitnessapi.com/data/floors-elevation-api"
---

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

> Every platform here counts floors, but the value types differ: the Google Health API's floors type holds an integer count, Health Connect's FloorsClimbedRecord and Wear OS's FLOORS hold a Double, with Google noting that Wear OS supports partial floors, and HealthKit's flightsClimbed counts flights of stairs in count units. Elevation differs more. Health Connect's ElevationGainedRecord and the Google Health API's altitude type are gains over an interval whose documented ranges include negative values, Wear OS reports ELEVATION_GAIN and ELEVATION_LOSS as two values that are never negative plus an ABSOLUTE_ELEVATION behind the fine-location permission, and HealthKit has no elevation sample type, only workout metadata keys. Google's floors type cannot be listed, only rolled up.

- Canonical: https://aifitnessapi.com/data/floors-elevation-api
- Last reviewed: 2026-10-18
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Floors Climbed and Elevation API: Floors, Elevation Gain and Altitude", AIFitnessAPI, https://aifitnessapi.com/data/floors-elevation-api

---

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

| Platform | Type | Value | Total with |
|---|---|---|---|
| Google Health API | [`floors`](/google-health-api/floors) | `count`, an integer from 0 to 1,000,000 per interval | rollUp or dailyRollUp, which return `countSum` |
| Apple HealthKit | [`flightsClimbed`](/healthkit-identifiers/flights-climbed) | count units, cumulative, from iOS 8.0 | a cumulative-sum statistics query |
| Android Health Connect | [`FloorsClimbedRecord`](/health-connect/floors-climbed-record) | `floors`, a Double from 0 to 1,000,000 | the `FLOORS_CLIMBED_TOTAL` aggregate, also a Double |
| Wear OS Health Services | [`DataType.FLOORS`](/wear-os-data-types/floors) | a Double per update | `FLOORS_TOTAL` during an exercise, or the daily form `FLOORS_DAILY` |

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](/google-health-api/floors) 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

| Platform | Type | What it is | Range or sign |
|---|---|---|---|
| Google Health API | [`altitude`](/google-health-api/altitude) | "the altitude gain (i.e. deltas), and not level above sea, for a user in millimeters" | `gainMillimeters`, `[-1000000000, 1000000000]` |
| Health Connect | [`ElevationGainedRecord`](/health-connect/elevation-gained-record) | "the elevation gained by the user since the last reading" | a `Length` from -1,000,000 to 1,000,000 meters |
| Wear OS | [`ELEVATION_GAIN`](/wear-os-data-types/elevation-gain) and [`ELEVATION_LOSS`](/wear-os-data-types/elevation-loss) | gain and loss in meters since the last update | never negative: "it will only be positive or 0" |
| Wear OS | [`ABSOLUTE_ELEVATION`](/wear-os-data-types/absolute-elevation) | "Absolute elevation at a specific point in time expressed in meters." | a sample, not a delta |
| HealthKit | none | elevation exists only as workout metadata | not applicable |

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`](/healthkit-metadata-keys#key-hkmetadatakeyelevationascended) and [`HKMetadataKeyElevationDescended`](/healthkit-metadata-keys#key-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.

## FAQ

### Can I list floors data points from the Google Health API?

No. Google's data-types table lists only reconcile, rollup and dailyRollup for the floors type, so there is no list operation to page through raw data points. Request a rollUp or dailyRollUp over the window you need and read countSum, the summed integer floor count. The type has a 1-minute storage resolution, webhook support and true-zeros support.

[Permalink](https://aifitnessapi.com/data/floors-elevation-api#faq-1)

### Does HealthKit have an elevation gain data type?

No sample type. HealthKit records elevation as workout metadata: HKMetadataKeyElevationAscended and HKMetadataKeyElevationDescended hold the cumulative elevation ascended or descended as a length quantity, set on a workout, a workout segment or a distance sample. For stairs, HealthKit has flightsClimbed, a cumulative count of flights climbed, available from iOS 8.0.

[Permalink](https://aifitnessapi.com/data/floors-elevation-api#faq-2)

### Can elevation gained be negative?

On two platforms the documented range allows it. Health Connect's ElevationGainedRecord accepts -1,000,000 to 1,000,000 meters, and the Google Health API's altitude type accepts gainMillimeters from -1,000,000,000 to 1,000,000,000. Wear OS Health Services instead splits ELEVATION_GAIN and ELEVATION_LOSS, and Google says each will only be positive or 0. Neither Google page says what a negative gain means, so define it before you store one.

[Permalink](https://aifitnessapi.com/data/floors-elevation-api#faq-3)

### Why is Wear OS floors climbed a Double?

Google's Health Services reference says partial floors are supported, so FLOORS is represented as a Double: the number of floors climbed since the last update, with FLOORS_TOTAL for the whole exercise and FLOORS_DAILY for the day. Health Connect's FloorsClimbedRecord is also a Double, while the Google Health API's floors count is an integer, so a value moved into the cloud type loses its fraction.

[Permalink](https://aifitnessapi.com/data/floors-elevation-api#faq-4)