Thryve’s technology is a middleware consisting out of a SDK, a data warehouse with added analytics and an API allowing you to easily access health and fitness data from medical devices and other consumer health sources. Our service dramatically reduces the time to integrate and interpret meaningful data and to monitor your users’ health 24/7.
Thryve integrates directly into existing Android, iOS and web-apps and unlocks a continuous stream of harmonized health data from a broad and growing selection of contemporary smart devices – from smartphones to fitness trackers to blood glucose meters.
Read on to find out how Thryve’s wearable API will save you time and headaches when integrating wearables and other smart devices into your digital health applications.
Thryve’s technology consists out of three main building blocks:
- The wearable SDK integrates directly into your iOS, Android or web application using your preferred native or cross-platform language and allows your users to connect their data sources in your application. The Thryve SDK consists out of different modules enabling the data upload of native data sources
- The Thryve wearable data warehouse stores all your users’ data including authentication tokens for data retrieval and actual health data from all connected sources in highest granularity. All user data is linked to a fully pseudonymized Thryve user token giving Thryve no information on who your user is. Your users’ data will be upon request enriched by Thryve’s scientifically proven analytics.
- The wearable API allows you to access the data you need with ease. If configured, we notify you about new incoming data through web-hooks. You can draw any data at any time through the REST API by calling the corresponding endpoint.
For an overview, please also refer to the data sources list. At Thryve we distinguish between three main concepts of data sources:
- Native data sources
Data sources storing health data locally on your users’ device like Apple Health, Google Fit (native) or Samsung Health are called native data sources. Data from native data sources is locally retrieved on your users’ device through the corresponding SDK module (-> see SDKs and modules).
- OAuth data sources
Data sources storing health data in the cloud like Fitbit, Garmin or Withings are called web data sources or OAuth data sources (due to the authorization protocol OAuth used by these sources). Data from OAuth data sources is drawn directly from the data sources’ server to Thryve’s server. When a user connects a web data source via OAuth the data source generates a pseudonymized authentication token which is routed via your app to Thryve’s server. This token allows Thryve to retrieve your users’ authorized health data.
- Direct access
At Thryve, we fundamentally believe in each user’s right to both transparency and control about his or her data. Enabling data sovereignty is at the core of our work. Unfortunately, not all health data sources think alike.
While most data sources already provide state-of-the-art native or oAuth-based interfaces to allow for data transfer, several data sources enable data transfer only using explicit user credentials. We call those data sources direct access.
As the access and retrieval of direct access data sources is error-prone, those data sources are considered as “experimental”. If you want to use our “experimental” data sources, please contact us as they are by default disabled to safeguard privacy.
Device manufacturers provide data in a variety of formats, metrics and reference standards. Thryve’s single Health API harmonizes data provided on a daily and minutely basis – allowing you to integrate just one set of data instead of hundreds.
In cooperation with various research partners, we detect and validate health patterns and indicators in customers’ health data. With Thryve, you will be the first to access meta-information on how fitness trackers indicate alcohol consumption or how smartwatches detect atrial fibrillation.
We refer to historic data to data that was created by the user prior to the data connection with your application. Different data sources allow for different timeframes to retrieve “historic data”.
Data privacy and security
Thryve is in use by a wide range of high-profile customers including governments, hospitals and health insurances in various settings with privacy certified applications. Privacy-by-design has been at our heart since our founding days as we are very much aware of the value of compliance in healthcare settings.
Regular data privacy and data security audits by certified external parties are part of our development process.
We work hard on making sure, integrating and using Thryve runs smooth with your existing data privacy processes. As Thryve works exclusively with de-identified data-sets that have been cleared from all individual information, your service remains the single trusted data authority for your users.
To get your health monitoring up and running with Thryve, all you need are your credentials (→ see Credentials) and two integration steps:
- Integrate the plug-and-play Thryve SDK and corresponding modules into your native or cross-platform app, so that your users can activate their health monitoring (→ see SDK Integration)
- Draw health data from different data sources (→ see Biomarkers for details) for each user (by using the corresponding authentication token) through our wearable API (→ see Wearable API).
What you need to start
When starting to use Thryve, you will receive a set of credentials required to use all functionalities of the Thryve SDK and the wearable API:
- Partner String
- The individual Partner String is required to access the wearable API. Typically, the partner string is your company or app name written in small letters. If we have configured an own tenant for you, the Partner String may also be used as a prefix in the URL to access your tenant. Example Partner String structure: mhealthapp Example structure of URL for your own tenant: mhealthapp.und-gesund.de
- You will receive your AppID upon signing the cooperation. If needed, you can also have multiple Apps registered.Example structure: FEh9HQNaa87cwdbB
- Next to the Partner String and the AppID, you will receive an AppSecret, which was introduced with SDK versions 2.0 and is also mandatory to perform API requests to the Thryve REST interfaces.Example structure: NL7nTegPm5DKt8LrBZP62HQz6VNZaGuM
- Web authentication
- The Thryve API is secured through a web authentication layer. Upon signing the cooperation, you receive a personal user and password.Example structure: healthapp-api / A7qmaxf9a
Configuring Partner specific Client ID
When connecting a data source your users will be forwarded to authorization pages or widgets of the corresponding data sources. Triggering this process requires two data-source-specific parameters:
- Client ID
To give you a head-start when integrating Thryve, we will provide you a generic set of client IDs so you can directly start testing the data source connections.
As the data source authorization pages display information like text and logos linked to the client ID’s developer account, we highly recommend you apply for your own Client ID and ClientSecret. The registration is mostly free and can usually be done via web-based forms. Please refer to our support page explaining the application process to get a client ID for all the corresponding data sources.
When applying for a custom ClientID most data sources will require you to define a Redirect URL, which is used to perform the redirection. Please use the following URL based on your Partner for the correct redirection:
Many data sources offer ping services (or Notifications / Subscriptions) that notify the data handler about newly uploaded data of users. When using own client IDs for data sources with ping services, please configure the settings accordingly to ensure smooth data retrieval by Thryve. For more information, please refer to the data sources overview.
When configuring the ping service of the affected data sources, please use the following endpoint:
Thryve’s service supports hybrid configuration of ClientIDs. This means you can use your own Client IDs for specific data sources, e.g., Fitbit, while other data sources, e.g., Garmin, use the default Client ID of Thryve. Please keep in mind that the data source authorization page cannot be modified, if you use Thryve’s ClientID.