Key Takeaways
- The Google Health API requires two separate things: one-time OAuth app verification by Google's Trust and Safety team, and an ongoing, accredited third-party CASA security assessment for restricted scopes.
- The trigger is sensitive or restricted scopes combined with more than 100 users. Below that threshold you can skip verification, but every user sees an "unverified app" warning at sign-in.
- CASA costs $500 to $4,500 depending on tier, takes two to six weeks, and renews annually from the date your Letter of Validation is approved.
- Whoever owns the Google OAuth client carries the assessment. Routing through a third-party integration layer, self-hosted or SaaS, does not move that responsibility off your organization.
- Reading the same data on-device through Health Connect (Android) or Apple Health (iOS) avoids Google's restricted-scope verification entirely, at the cost of needing your own mobile app and going through its own app store review.
If you are moving health data off Fitbit's API before it shuts down in September 2026, the natural landing spot is the Google Health API. It is the successor Google points developers toward, it aggregates Fitbit, Pixel, and other connected sources, and it is a straightforward REST API with no SDK required.
Then you request your first restricted scope and Google asks you to complete OAuth app verification and an annual CASA security assessment, and the conversation changes shape. This is not a Google Health API quirk. It is how Google treats any app requesting sensitive or restricted data on its platform, and it applies whether you are calling the API directly or through a layer like Open Wearables. What follows is what that process actually involves, what it costs, and where the responsibility genuinely sits.
Two Different Things: OAuth Verification and CASA
Google treats access to sensitive and restricted scopes as two separate checkpoints, not one.
OAuth app verification is a review by Google's Trust and Safety team. They look at your app's identity, every scope you request, and your justification for needing it. They also require an in-app disclosure at the point of consent, not just a line in your privacy policy. This is a one-time gate to get your app recognized rather than flagged.
CASA (Cloud Application Security Assessment) is a separate, ongoing requirement layered on top for restricted scopes, which cover most of what the Google Health API exposes. It is a security assessment performed by an accredited third-party lab against the OWASP Application Security Verification Standard (ASVS). A self-scan is no longer accepted on its own. You come out the other side with a Letter of Validation, which you then submit to Google.
Most teams hear "Google verification" and picture a form. It is closer to a compliance audit with a named external assessor and a formal deliverable.
What Triggers It, and What Happens If You Skip It
The trigger is the combination of scope sensitivity and user count. Apps requesting sensitive or restricted scopes with more than 100 users need verification. Under 100 users, you can skip it, which is fine for a pilot and not viable for production, because every user still sees an "unverified app" warning screen at sign-in. That screen alone is enough to kill trust in a health app, particularly one embedded in a clinical workflow.
What It Costs and How Long It Takes
Google sets the assessment tier based on your data sensitivity and scale, not a number you pick. The two tiers that matter for most health apps:
- Tier 2: two to three weeks
- Tier 3: four to six weeks
Cost runs from $500 to $4,500, paid to the assessor, with more sensitive data and larger scale pushing you toward the top of that range. The assessment is not a one-time cost. It renews annually from the date your Letter of Validation is approved.
If you are building on Google Health API for a product with real clinical or health-plan distribution, plan for the upper end of both the cost range and the timeline, and sequence the verification work to run alongside your build rather than gating launch behind it.
Who Actually Owns the Assessment
This is the part that surprises teams evaluating a wearable data platform, self-hosted or otherwise: going through a third-party integration layer does not move the assessment off you.
The verification and CASA requirement attach to whoever owns the Google OAuth client. The scopes belong to your app, so Google assesses your app and your organization, regardless of what infrastructure sits behind the OAuth flow. There is no arrangement with Open Wearables where a vendor holds the client on your behalf and inherits the audit, since it is self-hosted and the OAuth client is yours by design.
This is worth being precise about, because it cuts both ways:
- Keeping your own OAuth client (which is what happens when you self-host something like Open Wearables) means data flows from Google straight into your environment with nobody in the middle holding a copy of it. The cost of that is that the assessment sits with you.
- Using a SaaS aggregator that holds the OAuth client itself can mean the verification paperwork is technically theirs, but you inherit their scope set and their data handling practices, and you have no direct relationship with Google about your own users' data. For anything embedded in an EHR or handling PHI, that trade is usually the wrong one, since you lose visibility into exactly what the aggregator is doing with your patients' data on the other side of their client.
Neither path makes CASA optional. It changes who is answering the assessor's questions and who controls the answers.
What CASA Actually Tests: The Deletion Requirement
One of the concrete things CASA verifies is whether your app can delete a user's data on request, so it is worth being specific about what that looks like in practice rather than treating it as a checkbox.
In Open Wearables, deleting a user removes every stored data type for that user: records, timeseries, archived data, and derived scores, and it deregisters the OAuth connection with each connected provider in the same operation. There is also a narrower, provider-scoped version: you can wipe everything held for a single provider and revoke that specific connection while leaving the rest of the user's history intact.
That provider-scoped path has a nuance worth confirming with the team before an assessor finds it for you rather than treating it as settled. Session-based scores (tied to a single sleep session, for example) are more likely to trace cleanly back to the provider that produced them and disappear when that provider is disconnected. Scores computed from a rolling window across whichever sources were connected at the time are the harder case, and may not cleanly attribute to a single disconnected provider. If your deletion request is scoped to "delete this user," this distinction does not affect you, since full deletion clears everything regardless.
Because Open Wearables is open source, this is not something you have to take on faith. Your own security reviewers can read the deletion implementation directly, which tends to be the most useful property of building an evidence package on a self-hosted stack: every claim points at code your team can inspect rather than a vendor's word.
What a Platform Like Open Wearables Can and Cannot Do for You
The assessment itself has to come from an accredited third-party lab. Nobody providing your integration layer can be that lab, and be skeptical of anyone who implies otherwise.
What sits upstream of the lab is where help is genuinely useful:
- The evidence package: architecture and data-flow documentation, per-scope justifications, and retention/deletion documentation in the form assessors expect
- Hardening the deployment against the ASVS controls the assessment tests, before the lab finds gaps rather than after
- The in-app disclosure and consent flow, which is a common rejection reason and is inexpensive to get right up front
- Remediation on whatever the assessor raises, so findings do not sit unresolved in your backlog
None of this replaces the assessment. It reduces the odds of a failed first pass and shortens the time between opening the process and getting your Letter of Validation.
The Alternative That Skips Verification Entirely
There is a route that avoids Google's restricted-scope verification process altogether: reading the same underlying data on-device instead of through the cloud API.
On Android, Fitbit and other apps write into Health Connect, and reading from that on-device layer does not touch Google's restricted scopes at all. The equivalent on iOS is Apple Health. Data coverage broadly overlaps what the cloud API exposes, and in places goes wider, since Health Connect aggregates from more sources than just Fitbit and Pixel.
This is a real architectural choice, not a shortcut, and it comes with its own costs. It means shipping a mobile app on the user's device under your own brand, since the SDK has to run somewhere the user's data already lives. It adds a mobile app review process of its own (App Store or Play Store) on top of whatever else you are shipping. And it changes your product's install and onboarding flow: instead of a web-based OAuth consent screen, users need your app installed and Health Connect or Apple Health populated with their data before you can read anything.
Worth a note on maturity: neither path has been rigorously battle-tested at large production scale yet, since both are relatively new. Treat the on-device route as a real option to evaluate rather than an automatic default, and confirm current maturity and data-type coverage for your specific use case with the team building it before committing engineering time to it.
Which route fits depends on what your existing product looks like. If you already have a mobile app your users install, the on-device path is worth evaluating for the compliance cost it avoids. If your product is a web or backend service with no existing mobile footprint, standing up a mobile app purely to avoid CASA is its own significant scope of work, and the cloud OAuth path, verification included, is often the more pragmatic one.
The Decision, In Short
Moving off Fitbit's API means either the Google Health API or the on-device Health Connect/Apple Health path, and the Google Health API means OAuth verification plus annual CASA if you are past the pilot stage. That is true regardless of what sits behind your OAuth client. What changes based on your infrastructure choice is how much of the evidence package, hardening, and deletion behavior you have to build yourself versus what is already implemented and auditable in the platform you are building on.
If you are early in that decision, see how Open Wearables handles the Google Health API integration, including the OAuth flow, webhook handling, and data model the CASA evidence package would need to document.
See related articles
Google Health API: A Practical Guide to Getting Started
Google Health API and Google Health Connect: What's the Difference
Fitbit Web API Shutdown 2026: Migration Guide
Fitbit Alternatives for Developers
FAQ
What is the difference between OAuth verification and CASA?
OAuth app verification is a one-time review by Google's Trust and Safety team of your app's identity, scopes, and consent flow. CASA is a separate, ongoing security assessment by an accredited third-party lab against the OWASP ASVS standard, required for restricted scopes, and renewed annually.
Does going through Open Wearables get me out of Google's CASA requirement?
No. The verification and CASA requirement attach to whoever owns the Google OAuth client and requests the scopes, which is your app regardless of what integration layer sits behind it. Self-hosting Open Wearables means you keep your own OAuth client, so the assessment sits with your organization.
How much does a CASA assessment cost and how long does it take?
Cost runs from $500 to $4,500 depending on the tier Google assigns based on your data sensitivity and scale. Tier 2 assessments take two to three weeks, Tier 3 takes four to six weeks. The assessment renews annually from the date your Letter of Validation is approved.
What happens if I skip verification?
Apps under 100 users can operate without verification, which works for a pilot. Past that threshold, or with fewer users but the intent to scale, every user sees an "unverified app" warning screen at sign-in, which undermines trust in a health app.
Does CASA check whether Open Wearables can delete user data?
Yes, data deletion is one of the things CASA verifies. Open Wearables implements full user deletion (covering records, timeseries, archived data, and derived scores, plus deregistering provider OAuth connections) and a narrower provider-scoped deletion that revokes a single connection while preserving the rest of a user's history.
Is there a way to avoid the Google Health API verification process entirely?
Yes. Reading the same underlying data on-device through Health Connect (Android) or Apple Health (iOS) does not touch Google's restricted cloud scopes, so it avoids OAuth verification and CASA. It requires your own mobile app and its own app store review process, and is a less battle-tested path at scale than the cloud API today.