Blood Glucose API: How to Get Glucose Data Into Your App

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.

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 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 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.

Which should you pick?#

• iOS app reading what a meter or CGM already wrote: HealthKit bloodGlucose, read on-device. See the HealthKit integration guide 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.