Blood Glucose & CGM data from every wearable, in one schema
Continuous glucose monitoring streams normalised to a single unit, with insulin delivery alongside.
2 / 4
Providers connectable today
3
Webhook events in this family
mg/dL canonical, mmol/L conversion preserved
Canonical units
What blood glucose & cgm looks like through one API
Continuous glucose monitoring is the fastest-moving category in consumer health data and the one with the least forgiving accuracy requirements. A CGM produces a reading every five minutes, indefinitely, and users act on those readings — which makes unit handling and gap handling correctness problems rather than polish problems.
WearLink normalises glucose to mg/dL as the canonical unit while preserving the provider's original unit and value, because the mg/dL and mmol/L conventions split cleanly along regional lines and a silent conversion error is roughly an eighteen-fold mistake. Nothing about the source reading is discarded.
Insulin delivery is carried as its own series where the source reports it, so closed-loop and therapy-adherence products can align dose with response without a second integration.
Where providers disagree
The part that costs you weeks if you build this yourself. None of the following is a WearLink limitation — it is how the underlying providers actually behave.
mg/dL versus mmol/L is a factor of ~18
US products work in mg/dL; most of the rest of the world uses mmol/L. A misconverted value is not subtly wrong, it is catastrophically wrong, and it will look plausible to code that has no unit check. Always read the unit field rather than assuming a default.
Gaps are normal and meaningful
Sensor warm-up, out-of-range transmitters and sensor changes all produce gaps. Interpolating across them fabricates readings a user may act on. Treat a gap as a gap and render it as one.
Regulatory posture differs from fitness data
Glucose data is health data in the strictest sense in nearly every jurisdiction. Access is gated by the provider, and what you may store, display and infer is constrained. Dexcom in particular has explicit terms on retention and display that are stricter than any fitness provider.
Readings arrive out of order after a connectivity gap
A CGM transmitter buffers readings when the phone is out of range and uploads the backlog on reconnection. That backlog arrives after readings with later timestamps have already been delivered, so an append-only pipeline that assumes monotonically increasing time will interleave the history incorrectly. Sort by the reading timestamp, never by arrival order. Sensor sessions also have distinct accuracy phases — the first hours after insertion are less reliable than the middle of a session — and the payload does not flag which phase a reading came from.
Providers that supply blood glucose & cgm
Status is read from the same provider table the rest of the site uses, so nothing here can claim a provider is connectable when it is not. Coverage also varies by hardware generation within a brand.
| Provider | Category | Status |
|---|---|---|
| Dexcom | Cloud OAuth | Onboarding |
| Ultrahuman | Cloud OAuth | Onboarding |
| Apple Health | Mobile SDK | Mobile SDK |
| Google Health Connect | Mobile SDK | Mobile SDK |
Webhook events for blood glucose & cgm
Subscribe to the summary event for settled records, and to the series streams when you need the underlying samples. Event names below are generated from the backend enum, so they cannot drift out of date relative to the API.
Summary object
blood_glucose.created
Series streams
series.blood_glucose.createdseries.insulin_delivery.createdFrequently asked questions
- Which CGM sources does WearLink support?
- Dexcom and Ultrahuman on the cloud side, plus glucose written into Apple Health or Health Connect by any app the user has authorised. Connection status is shown in the table on this page.
- What unit does the API return?
- mg/dL as the canonical field, with the provider's original unit and value preserved alongside so no conversion is irreversible.
- Can I use WearLink CGM data in a clinical product?
- The API delivers the data; the regulatory obligations remain yours and depend on your jurisdiction and claims. Dexcom access in particular carries provider-side terms on retention and display that you must satisfy directly.
Related data types
15 normalised data families in total — see them all or browse integrations by provider.