As of October 2, 2026, there is no documented public API for importing Health Guardian’s insulin-resistance or blood-pressure-trend reports. The public data-type catalog and REST reference contain no matching report type or endpoint. Developers can work with separately documented records such as heart rate, HRV and sleep, subject to authorization and data availability.
That is a slightly disappointing answer, because there is some clever engineering behind the announcement. A wearable finding a useful pattern across weeks of data is an appealing prospect. You can see why someone building a health app would immediately start making room for it. We would like those reports to be available too.
The gap deserves a closer look. Google's consumer feature, the model's inputs and the records exposed to developers are three different things. Following those distinctions makes it easier to appreciate the technology and work out what you can actually use.
The monthly part deserves some attention
Google announced Health Guardian on August 12, 2026. Insulin resistance trends use several weeks of physiological data; blood pressure trends use pulse and motion patterns across a month. The Google Health app presents monthly summaries, with Health Coach helping users interpret them. Google scheduled the two trends for September 2026, with availability depending on device and region. Health Guardian announcement.
We like the decision to work over a longer period. A monthly review gives a wellness product room to discuss patterns without making every fluctuation the main event. There is also an obvious cost: waiting. Google's September 24 update says trend insights arrive on the first of each month, once there are at least seven days of data in a month for insulin resistance and five consecutive days in a week for blood pressure. Buying a compatible device and receiving an assessment are separate moments. Report requirements.
The rollout has moved on, too. On September 24, Google announced that users could begin setting up blood pressure trends, insulin resistance trends and sleep breathing quality in the app that week. It said the tools were included free with Pixel Watch 3, 4 and 5, with the first trend reports arriving in early October. Fitbit Air access was still scheduled for later in the year, with Google Health Premium. That confirms a consumer rollout; the developer-access question remains separate. Rollout announcement.
The intended use matters as much as the timing. Google describes the trends as general wellness information: they do not provide real-time clinical readings, screen for diabetes or hypertension, or support medication adjustments. A slower assessment of a pattern has its own potential value. It does not need to acquire the job description of a clinical monitor to be interesting. Google's stated limitations.
A heart-rate number leaves a lot behind
The WavesFM paper linked from Google's announcement is worth a detour. It describes learning from physiological waveforms, including photoplethysmography and accelerometry. First, an encoder learns representations of short waveform segments. A temporal encoder then works across multiple days. The authors distinguish this approach from methods that use coarse features such as heart rate and step counts over longer periods. WavesFM paper.
This is the detail we find most compelling. The architecture gives attention to both the short signal and the longer sequence. It isn't asking a daily total or a heart-rate value to retain everything that might have been useful in the original waveform.
It also explains why access to heart-rate records would not let a developer casually recreate the result. The public vitals guide describes heart-rate samples with a beats-per-minute value and metadata for motion context and sensor location. Those are useful records, but they are a different representation from the waveform inputs in the research. Heart-rate data documentation.
Our engineering reading is straightforward: sharing a watch as a source does not mean sharing a model's inputs, its trained parameters or its processing rules. An app can produce its own analysis from the data it receives. Calling that analysis Google's assessment would conceal the most consequential difference between the two.
There is another layer after the assessment: explaining it. Google positions Health Coach as a way to understand Guardian information, and requires Google Health Premium, the app and an internet connection for Coach. That describes a consumer experience, not a documented response containing the explanation. Coach requirements.
The blood-pressure names do not help
The Google Health API is Google's evolution of the Fitbit Web API, using Google OAuth 2.0. Available device data depends on the functionality supported. So there is a documented integration route here, with plenty worth using. Google Health API overview.
Blood pressure is where an enthusiastic reading can get ahead of the documentation. The current data-type catalog, updated October 1, contains no blood-pressure entry or Guardian assessment type. That day's release adds a v4beta preview channel and skin-temperature-sensors. Useful new access, but it doesn't supply the missing Guardian report. The current roadmap no longer lists the earlier Q3 blood-pressure item. Data-type catalog, October 1 release notes, API roadmap.
Meanwhile, Android's separate Health Connect API has a perfectly real BloodPressureRecord. It contains systolic and diastolic pressure, a timestamp and contextual fields such as measurement location. This is a conventional measurement record. Finding it does not solve the Guardian import question, tempting as it is to stop searching once the words “blood pressure” appear in a reference page. Health Connect reference.
Glucose has a similar distinction. The Google Health API documents blood-glucose concentration with measurement context; that record is not an insulin-resistance assessment. Its vitals guide also covers daily resting heart rate, HRV, oxygen saturation and respiratory-rate sleep summaries. Vitals guide. Sleep sessions and stage intervals have their own documentation, and should retain their own meaning rather than becoming a substitute label for Guardian's sleep breathing quality assessment. Sleep guide.
The public DataPoint schema contains no matching Guardian assessment payload in the reference reviewed for this article. That missing definition is the unresolved part. More permission to read an existing type cannot change what that type represents. DataPoint reference.
There is useful work on this side of the API
We would still be interested in a monthly review built from recorded sleep sessions and daily resting heart rate. It could put routines and observations alongside each other, with enough room for someone to recognize a change they care about. That experience can stand on its own; it doesn't need a borrowed Guardian label.
Some of the least glamorous fields would make it considerably better. Google's DataPoint has an optional dataSource object containing recording-method information and device or application details. Keeping that information, when present, helps explain where an observation came from. DataSource reference. It's a small field we'd hate to lose on the way to a prettier chart.
A month with missing nights should look different from a month of consistently short sleep. A device change may deserve a note where the source information supports it. These are small design choices, but they give the person reading the chart a chance to understand it. A beautifully smooth line is a poor consolation if the app quietly invented the observations between two points.
The documented webhooks provide a practical way to keep such a review current. They identify the user, data type and affected intervals when data changes, allowing the app to query the update. Google recommends idempotent handling because retries can produce duplicate notifications. Webhook guide. New sleep data could trigger a recalculation of the app's review; that event would say nothing about whether a Guardian report had changed.
Access still takes work. Google's documentation says it is not onboarding new projects at present. All Health API scopes are restricted and require privacy and security review; the catalog maps types to their permissions and supported operations. These are practical constraints on the documented integration, regardless of how appealing the consumer announcement is. Access requirements, scope mapping.
What we would most like to inspect next is a public assessment resource: the period it covers, the meaning of its result and what happens when more data arrives. Those details would decide whether a report could support a useful conversation in another app. A documented Guardian report would give developers something new to build with, and a few schema decisions we'd actually enjoy arguing about.
