--- title: "Blood Glucose API: How to Get Glucose Data Into Your App" canonical: "https://aifitnessapi.com/data/blood-glucose-api" cluster: "Health Data" primary_query: "blood glucose api" last_reviewed: "2026-08-12" description: "Read glucose via HealthKit bloodGlucose and Health Connect BloodGlucoseRecord. Meter and CGM sourced, mg/dL vs mmol/L traps, and the medical-claim line." publisher: "AIFitnessAPI — independent, not sponsored" cite_as: "\"Blood Glucose API: How to Get Glucose Data Into Your App\", AIFitnessAPI, https://aifitnessapi.com/data/blood-glucose-api" --- # Blood Glucose API: How to Get Glucose Data Into Your App > Blood glucose reaches your app second-hand: a fingerstick meter or a continuous glucose monitor measures it and its companion app writes it into the platform store, which you then read on-device via Apple HealthKit's HKQuantityTypeIdentifierBloodGlucose or Android Health Connect's BloodGlucoseRecord. The value is genuinely measured, but not all glucose is the same measurement - Health Connect requires a specimenSource field distinguishing interstitial fluid from capillary blood, plasma, serum, tears, or whole blood. The two traps that bite hardest are units, since samples may be in mg/dL or mmol/L by region, and meal context, which Health Connect makes mandatory and Apple exposes only as optional metadata. Best pick: the on-device stores for a single platform, or an aggregator such as Terra, Rook, or Spike server-side - and keep the framing wellness, not medical guidance. - Canonical: https://aifitnessapi.com/data/blood-glucose-api - Last reviewed: 2026-08-12 - Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored - Cite as: "Blood Glucose API: How to Get Glucose Data Into Your App", AIFitnessAPI, https://aifitnessapi.com/data/blood-glucose-api --- Glucose is the metric where a consumer health app stands closest to a regulated medical device without being one. The reading in the health store almost never came from a fitness wearable — it came from a fingerstick meter or a continuous glucose monitor, hardware that is cleared and sold as a medical device, and it arrived in HealthKit or Health Connect because the manufacturer's companion app wrote it there. Your app is a downstream reader of somebody else's clinical-grade instrument, and both the engineering traps and the product constraints follow from that. ## Where you can get glucose data Identifier names, constants, and permission strings change. Each row below records where the claim came from and when it was checked. | Source | How you access it | What it exposes | Verified from | | --- | --- | --- | --- | | Apple HealthKit (iOS) | On-device read, per-type permission; no cloud pull | `HKQuantityTypeIdentifierBloodGlucose`, listed under Lab and Test Results. Mass-per-volume units, discrete aggregation. Optional `HKMetadataKeyBloodGlucoseMealTime` metadata | Apple `bloodGlucose` and `HKQuantityTypeIdentifier` references, fetched 2026-08-12 | | Apple HealthKit (related) | On-device read, per-type permission | `HKQuantityTypeIdentifierInsulinDelivery` in international units, cumulative aggregation, with `HKMetadataKeyInsulinDeliveryReason` metadata; dietary carbohydrate types under Nutrition | Apple `insulinDelivery` and `HKQuantityTypeIdentifier` references, fetched 2026-08-12 | | Android Health Connect | On-device read, per-record permission; no cloud pull | `BloodGlucoseRecord` in the Vitals category, instantaneous. Mandatory fields `level`, `specimenSource`, `mealType`, `relationToMeal`, `metadata`, `time`. Permissions `android.permission.health.READ_BLOOD_GLUCOSE` and `WRITE_BLOOD_GLUCOSE` | Android Health Connect data types page and `BloodGlucoseRecord` reference, fetched 2026-08-12 | | Terra | One cloud API plus webhooks over many providers | CGM and glucose are listed in its normalized schema | Our [health-data aggregator APIs](/fitness-apis/health-data-aggregator-apis) page | | Rook | One cloud API plus on-device SDKs | Glucose and CGM across a stated 400-plus sources; Dexcom is among the providers where you bring your own developer credentials | Our [health-data aggregator APIs](/fitness-apis/health-data-aggregator-apis) page | | Spike | One cloud API reaching into medical devices, EMRs, and lab tests | Markets Dexcom among 500-plus wearables and platforms | Our [health-data aggregator APIs](/fitness-apis/health-data-aggregator-apis) page | | Fitbit, Garmin, Oura, WHOOP | Cloud OAuth 2.0 | Blood glucose is not documented on our pages for any of these — verify with the vendor before planning around it | — | One access-model note worth internalizing before you design: HealthKit and Health Connect are permissioned on-device reads with no server endpoint to call, while aggregators are server-side and post-sync. See [on-device vs cloud health data](/learn/on-device-vs-cloud-health-data) for how that shapes latency and where the data ends up living. ## Measured — but of what, by what, and when Glucose is genuinely measured, not modeled. The nuance is that "glucose" names several different measurements that are not interchangeable, and Health Connect makes that explicit in its schema: `specimenSource` is a mandatory field with constants for `SPECIMEN_SOURCE_INTERSTITIAL_FLUID`, `SPECIMEN_SOURCE_CAPILLARY_BLOOD`, `SPECIMEN_SOURCE_PLASMA`, `SPECIMEN_SOURCE_SERUM`, `SPECIMEN_SOURCE_TEARS`, `SPECIMEN_SOURCE_WHOLE_BLOOD`, and `SPECIMEN_SOURCE_UNKNOWN`. Treat that field as load-bearing. A continuous monitor sampling interstitial fluid and a fingerstick meter sampling capillary blood are measuring different compartments with different devices, and dropping both into one trend line without labelling the specimen is how you ship a chart nobody can interpret. Apple's HealthKit type carries no equivalent required field, so on iOS the specimen distinction usually has to come from the sample's source app and metadata instead — plan for that asymmetry if you sync across platforms. There is also a provenance point that has nothing to do with sensors. A user can type a number into the Health app by hand. Manual entries, meter uploads, and CGM streams all land in the same type, so if the distinction matters to your feature, inspect the source rather than assuming a device wrote it. ## Units: the trap that produces wrong numbers, not missing ones Most data-type gotchas produce empty results, which are easy to notice. This one produces plausible, wrong ones. Apple documents that blood glucose samples may be measured in mg/dL (milligrams per deciliter) or mmol/L (millimoles per liter) depending on the region, and that the Health app lets users select their preferred units for both display and manual entry. Apple's documented remedy is to read the user's preference with `preferredUnits(for:completion:)`, and if your app connects to a glucose meter using different units, alert the user — Apple even suggests recommending they change their preferred units to match the meter. Never assume a unit; always read one and always store it next to the value. Apple documents one more constraint that is easy to miss and hard to debug later: do not save samples to HealthKit when the blood glucose meter is processing control solution. Control-solution runs are quality checks on the meter, not readings from the person, and writing them pollutes the user's record permanently. ## Meal context is part of the reading A glucose value without meal timing is close to meaningless, and both platforms model that, differently. Health Connect makes it mandatory. `BloodGlucoseRecord` requires both `mealType` and `relationToMeal`, and the relation constants are `RELATION_TO_MEAL_GENERAL`, `RELATION_TO_MEAL_FASTING`, `RELATION_TO_MEAL_BEFORE_MEAL`, `RELATION_TO_MEAL_AFTER_MEAL`, and `RELATION_TO_MEAL_UNKNOWN`. Apple makes it optional and coarser: `HKMetadataKeyBloodGlucoseMealTime` indicates the timing of a sample relative to a meal, using `HKBloodGlucoseMealTime` values of `preprandial` and `postprandial`. That is a five-value required enum on one platform and a two-value optional metadata key on the other. Fasting, in particular, has no direct Apple equivalent — decide how you round-trip it, document the mapping, and expect a lossy conversion in at least one direction. ## Sensitivity: read the data, do not practise medicine This is the section to get right before the code. Glucose data usually originates from a device regulated as a medical device, and it is used by people managing a chronic condition, but that does not make your general-wellness app a clinical tool — and presenting it as one is where products get into trouble. Do not compute or display dosing suggestions. Do not generate alerts framed as clinical warnings such as low or high thresholds phrased as instructions. Do not describe your app as monitoring or managing diabetes. Our page on [FDA regulation of fitness apps](/compliance/fda-fitness-app-regulation) covers where general-wellness framing ends and software-as-a-medical-device begins; treat that line as a product decision made deliberately, with counsel, not one you drift across through copywriting. The privacy handling is the same discipline as any sensitive health type, and glucose is Apple's own worked example of it: Apple's privacy documentation illustrates HealthKit's per-type granularity by noting that a user could let your app read step count data while preventing it from reading blood glucose levels — and that your app is never told a read was denied, so from its point of view no data of that type exists. Build an empty state that copes with that silently. Beyond permissions, Apple's HealthKit rules prohibit using the data for advertising, disclosing it to third parties without express permission (and even then only to parties that also provide a health or fitness service), and selling it to advertising platforms, data brokers, or information resellers, and require a privacy policy. Storage and retention obligations are covered in our guide to [storing health data securely](/compliance/store-health-data-securely). ## Which should you pick? - **iOS app reading what a meter or CGM already wrote:** HealthKit `bloodGlucose`, read on-device. See the [HealthKit integration guide](/integrate/healthkit) for setup and permissions. - **Android:** Health Connect `BloodGlucoseRecord`, and make use of the mandatory `specimenSource` and `relationToMeal` fields rather than ignoring them. - **Server-side across many users and devices:** an aggregator. Terra, Rook, and Spike are the ones our pages document as covering glucose or CGM sources. Note that several popular providers, Dexcom among them, commonly require you to register your own developer or partner credentials regardless of which aggregator you pick. - **Direct device integration:** going straight to a CGM manufacturer's API is a partner relationship with its own approval process. Verify terms and availability with the vendor; nothing on our pages substitutes for that. ## Before you ship Confirm the current identifiers, constants, permission strings, and metadata keys against Apple's and Google's live references. Store the unit alongside every value and read the user's preferred unit rather than guessing. Preserve specimen source and meal relation through your pipeline instead of flattening them. And keep the product framing honest: you are displaying a measurement someone else's regulated device produced, not offering medical guidance about it. ## FAQ ### Where does blood glucose data in HealthKit and Health Connect come from? Almost never from a fitness wearable. It comes from a fingerstick meter or a continuous glucose monitor, hardware sold and regulated as a medical device, whose companion app writes the reading into the platform store. Users can also type values in by hand. Manual entries, meter uploads, and CGM streams all land in the same data type, so if the distinction matters to your feature, inspect the sample's source rather than assuming a device produced it. [Permalink](https://aifitnessapi.com/data/blood-glucose-api#faq-1) ### What units do blood glucose samples use, and how do I avoid a unit mix-up? Apple documents that blood glucose samples may be measured in mg/dL (milligrams per deciliter) or mmol/L (millimoles per liter) depending on the region, and that the Health app lets users pick their preferred units for display and manual entry. Read that preference with preferredUnits(for:completion:) rather than assuming one, and Apple advises alerting the user if your connected meter uses different units. Always store the unit alongside the value. This trap produces plausible wrong numbers rather than empty results, which is what makes it dangerous. [Permalink](https://aifitnessapi.com/data/blood-glucose-api#faq-2) ### Can I read continuous glucose monitor data through a fitness API? Usually indirectly. On a phone you read whatever the CGM's companion app wrote into HealthKit or Health Connect. Server-side, our pages document Terra as normalizing CGM and glucose, Rook as covering glucose and CGM across a stated 400-plus sources, and Spike as marketing Dexcom among its providers. Note that several popular providers, Dexcom among them, commonly require you to register your own developer or partner credentials regardless of which aggregator you use. Going direct to a CGM manufacturer is a partner relationship with its own approval process. [Permalink](https://aifitnessapi.com/data/blood-glucose-api#faq-3) ### Is a glucose reading measured or estimated? Measured, not modeled - but glucose names several different measurements that are not interchangeable. Health Connect makes this explicit with a mandatory specimenSource field carrying constants for interstitial fluid, capillary blood, plasma, serum, tears, whole blood, and unknown. A continuous monitor sampling interstitial fluid and a fingerstick meter sampling capillary blood are measuring different compartments with different devices, so do not merge them into one unlabelled trend line. Apple's type has no equivalent required field, so on iOS that context usually has to come from the source app and metadata. [Permalink](https://aifitnessapi.com/data/blood-glucose-api#faq-4) ### What must a wellness app avoid claiming about glucose readings? Do not compute or display dosing suggestions, do not frame alerts as clinical instructions, and do not describe your app as monitoring or managing diabetes. Glucose data typically originates from a regulated medical device and is used by people managing a chronic condition, but that does not make a general-wellness app a clinical tool, and presenting it as one moves you toward software-as-a-medical-device territory. Treat that line as a deliberate product decision made with counsel rather than something you drift across through copywriting. This is not legal or medical advice. [Permalink](https://aifitnessapi.com/data/blood-glucose-api#faq-5)