Welcome to the WeFitter developer portal!
The aim of this section is to offer you, the new developer, all the information required to successfully set up our API integration with your platform. It is important to acknowledge that WeFitter is undergoing continuous improvements and developments. Therefore, we are making all possible efforts to keep this document up do date.
Before starting
In order to start implementing, you need to have your own set of WeFitter credentials. Please contact us if you did not get any credentials but you have requested our API.
Who are we?
Thunderbyte.AI is a full focused AI/ ML company building AI powered software products since 2009. At Thunderbyte.AI we work in an open, autonomous, informal and down-to-earth culture. Our office is located next to the Martini Hospital in Groningen. Within Thunderbyte.AI we work on many healthcare-related products. Our strength is working together on the basis of equality and improving each other.
WeFitter is an online service provider that enables apps and platforms to connect to well-known fitness apps and wearables. Lifestyle and health data collected from these wearable connections is combined with gamification elements such as challenges, leaderboards and point systems via WeFitter API. WeFitter helps apps and platforms implement the above components in order to collect valuable data and create more engagement on their platform. It is a product that will be potentially developed towards self-learning using artificial intelligence (AI) and machine learning. In this way, customers can create personalized and substantiated advice and journeys.
Let’s make IT fit!
Our terminology
Account = The account is the group of profiles that pertains to a client.
Admin = Administrator. The administrator is the client account manager/owner and is responsible for the client group profiles. The admin can modify and access the profiles and their data.
App = The app refers to the sub-group of profiles pertaining to an account. For example, the account usually covers the company, and the app can be a company department that is creating a group for fitness tracking and gamification. These apps can then be split further into teams.
Authentication = The process of accessing the WeFitter API. The authentication process involves receiving a ClientID and ClientSecret that are used to retrieve a bearer token. See Token below.
Bearer = Authentication token of three types. Basic (used to create administrator bearer tokens), administrator bearer tokens (for administrators) and profile bearer tokens (for logged-in profiles).
Challenge = Gamification feature of the WeFitter API. The challenge allows teams of profiles or individual profiles to compete against each other or to reach a specific goal.
Connection = Connections are the links between profiles and their wearables.
Notification = Send a notification to all devices for the specified profiles. The data will be sent to the client in a specific format.
Profile = Profiles are containers for wearables data. The profiles can be seen as an extension of users in a different system. Profiles are anonymous objects which can participate in teams and challenges. Keep in mind, listing profiles and creating profiles need an administrative bearer token, all profile specific actions need a separate bearer token that is returned after creating a profile. This bearer token is used in place of the administrative bearer token. (see profile create action for more information)
Push notification = Notification that is activated from the application and
SDK = Software Development Kit.
Team = A group of profiles that partake in the same activities, challenges and are usually related to or involved with the same client/organization.
Token = Before any calls can be made to WeFitter, BasicAuthentication is needed to verify the identity of the requesting party. This call will result into a Bearer token which has administrator privileges and is valid for one day (24 hours). This token can be used to create profiles, challenges, etc. The returned bearer is a JWT (JSON Web Token).
About the WeFitter API
WeFitter is a REST API that helps you retrieve, analyze, understand and leverage health data from end users. The API is comprised of two main components that are synergized to maximize the amount and quality of health data generated: health data integration (activity tracking apps & wearables) and gamification.
The WeFitter API can support the data model generation based on an end user’s health data. Through a balanced blending of gamification and wearable data, the predictions on a person's health and lifestyle are made possible through the API. WeFitter is constantly evolving, thus aiming to create a perfect T-shaped model, where multiple wearables can be supported while offering a wide variety of data availability.
API Components
Activity tracking wearables and apps
Today’s market of activity tracking wearables and apps available is continuously expanding. These apps and devices are used to collect various (health) information from their users, such as activity type, height, weight, sleep cycles, calories burned, stress levels and heart rate. The WeFitter API collects these data clusters from popular app and wearable brandsand stores them in a unified format, which you will benefit from once integrating the API.
If there is wearable or app not listed in our API package that you would be interested in, we are open to explore the possibilities of adding new connections. Please share your suggestion here!
Supported platforms overview
Wefitter is connected your Fitbit/Google/Withings/Garmin etc account, and not directly to the wearable itself. So in order for us to get data, the wearable needs to have synced with the provider (e.g. Fitbit, Google, etc.)
Data aggregation time
All the data that is retrieved from wearables and their respective provides is directly influenced by the provider. This is highly important when discussing update frequency. To be more specific for Fitbit, Strava, Withings and Polar, the update time is considered fast, as it works in an "event-driven" manner. Thus, when you complete a workout on Fitbit, WeFitter is directly notified that for the Fitbit wearable, there is new data that can be retrieved (pulled). On the other hand, for Googlefit, the data retrieval (pull) happens according to an interval. Therefore, WeFitter is bound by rate limits, resulting in less frequent updates.
Data deduplication
WeFitter makes use of data deduplication. Data deduplication is a process of eliminating data copies while decreasing storage capacity requirements. How does it apply to the WeFitter API? Since the WeFitter API connects to multiple wearables and apps, the client end-users might make connections with more than one platform.
This means that, while more than one platform tracks their activity, WeFitter collects the data from all platforms. These platforms might, in turn, collect the same data. The WeFitter API ensures that the data is collected in a unique numerical form, and that it is stored to portray an aggregate and complete tracking of the end-user’s activity.
In a practical example, data deduplication happens as such. A user tracks their activity using both GoogleFit and Apple Health simultaneously. The WeFitter API identifies the timestamps of the workout and inputs the data only one time. By this, the user can make use of multiple platforms for activity tracking, while having the most accurate results in the WeFitter API.
Note: At the moment, Strava is having a special case of deduplication that cannot be avoided in the current version of the API. If a user will do a training together with someone else, and both these users are tracking the activity at the same time, Strava considers it as two distinctive workouts.
Practical example: User A is doing a workout together with User B. Both Users are tracking the activity on Strava, to share it with their networks. User A tags User B in the post, and vice versa. Strava considers this as two separate workouts done by both User A, respectively User B. The WeFitter API will take both workouts in the overview.
