RunKeeper‘s (@runkeeper) recently announcedintegration with MyFitnessPal enables users to connect their accounts on the two systems to automatically sync MyFitnessPal tracked calories consumed (i.e. calories added) into RunKeeper while also syncing RunKeeper tracked fitness activities (calories subtracted) into MyFitnessPal. Weight measurements are also synchronized bidirectionally between the two systems so that your latest weight is consistent between the two.

But there’s an added bonus for other RunKeeper partners and members of the Health Graph community. Both calories consumed and weight measurements synchronized from MyFitnessPal to RunKeeper are available to all Health Graph API developers. Calories appear as Nutrition sets with values in the calories field and weight measurements appear in Weight sets. Both of these nutrition and weight sets will have a source value of ‘MyFitnessPal‘ to indicate their origin.

We hope that access to the additional MyFitnessPal-originated data will help you build even more amazing things for our collective user community!

One question we receive fairly often from Health Graph (@healthgraphapi) partners is how to validate that fitness activities (runs, walks, bike rides, etc.) read out of the Health Graph platform were GPS-tracked versus manually entered by the user. Rewards partners a la Earndit and GymPact, corporate wellness providers like Virgin HealthMiles, and forward-thinking brands are often keen to differentiate between tracked versus manually entered activities as part of their programs’ anti-fraud efforts.

So how do you tell the difference between GPS and manual activities?

Each item in the Fitness Activity feed has ‘source‘, ‘entry_mode‘, and ‘has_path‘ fields. These let you determine whether the activity was originally submitted as a GPS-tracked activity. For example, a RunKeeper (@runkeeper) mobile app GPS-tracked run should have values of “RunKeeper“, “API“, and “true” for the aforementioned fields, respectively.

If you are interested in including GPS-tracked sources from other Health Graph partners’ activity trackers, you can include them in your ‘source‘ filtering. In addition, if you need to differentiate by type of activity (i.e. running, walking, cycling, etc.) you can use the ‘type‘ field.

Using these fields should let you skip any activities for which the user simply entered statistics, or originally entered the route map (path) via the Web. For more details on these fields and their usage, please refer to the Health Graph fitness activities documentation, especially the array structures section.

Caveat: The only reliable way to verify whether a user has subsequently edited the map associated with a saved GPS-tracked activity is to manually check each point’s ‘type‘ (a value of “manual” means it has been edited). For efficiency’s sake, we don’t save that information anywhere else in the Health Graph platform and we retrieve points only when full data for the activity is requested. That said, we have found that most users do not edit maps after the fact.

Bill Day: Please tell us about yourself and Pact.Yifan Zhang: A classic dormroom to startup story, I co-founded Pact with my Harvard classmate Geoff Oberhofer. We were both fascinated by a behavioral economics principle that people are motivated much more by loss than rewards.

We decided to first tackle the specific problem of getting people to the gym more often, and launched GymPact on January 1st, 2012.

BD: What is the “elevator pitch” for why someone should use GymPact?YZ: Do you pay for an expensive gym membership but can never find the time to use it? GymPact is an iPhone app that lets you earn cash rewards for checking in at the gym, paid for by non-exercisers!

You can make a Pact to work out, choose how much money you’ll put on the line to motivate you, and earn cash when you meet your Pact. Our over 45,000 GymPact users are 90% successful at getting to the gym on committed days.

BD: How did you get started using the Health Graph API?YZ: Ever since we launched, our users have asked to count outdoor activities (runs, walks, bike rides) toward their Pact. The Health Graph platform has allowed us to easily partner with awesome products like RunKeeper to give our users a feature they wanted.

BD: How is using the Health Graph benefiting your business?YZ: We announced our integration with the Health Graph a few weeks before the launch, and the response was overwhelming! We had over 1,000 people sign up for our beta list on the first day, and tons more likes/RT’s on social media.

BD: Which portions of the Health Graph API do you use, and why?YZ: Right now, we are pulling RunKeeper GPS-tracked activities from the API so that we can automatically count them toward GymPacter’s Pacts.

BD: What do you like about the Health Graph? What would you like to see changed?YZ: The integration was so simple! There were very few bugs, which allowed us to focus on the product and experience rather than the engineering challenges of integration. We see no changes needed for the current version of what we’re doing.

BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?YZ: We would like to have verified activities marked specifically, since we would like to pull data from other Health Graph-integrated apps as well as RunKeeper.

BD: Can you share any future plans for Pact? What’s coming next that your users will be excited about? Does the Health Graph play a role in that, and if so, how?YZ: One big thing is that we have an Android app now in private beta! You can sign up for it on our homepage or here. Also, we’re looking to partner with other health apps to incentivize verified healthy activities. The Health Graph is huge for making those partnerships simple!

Gil Blander: I am the founder of Segterra, the company that created InsideTracker, the most advanced blood analysis program.

InsideTracker is an innovative, web-based platform that combines blood analysis with your demographic information and unique goals to create a roadmap to optimal wellness and performance. The program recommends simple and tangible interventions, such as changes in food, supplements, lifestyle, and exercise, to help our users achieve their goals.

BD: What is the “elevator pitch” for why someone should use InsideTracker?

GB: Our bodies are our most valued possessions. InsideTracker gives you information and tools to help you perform at your most efficient and optimal level every day.

A good analogy is taking your car in for service every 5000 miles. The technician runs the computer diagnostic and then tells you what you should do to keep your car running in the best condition possible.

Every 3-6 months, getting your blood drawn and analyzed by InsideTracker tells you the current state of your body. It’s like having a window inside yourself to see exactly how you are doing. That knowledge combined with InsideTracker’s recommendations for simple lifestyle and nutrition changes empowers you to keep your body in the best possible condition.

BD: How did you get started using the Health Graph API?

GB: Our team was looking for partners who shared our goal of giving customers control of their wellness and performance. We were really excited to have the opportunity to integrate with RunKeeper. We think that there can be important synergies between InsideTracker and other companies using the Health Graph platform.

BD: How is using the Health Graph platform benefiting your business?

GB: The Health Graph platform has an extensive community of users who want to track their fitness and performance. It’s a perfect fit for InsideTracker and for our customers.

BD: Which portions of the Health Graph API do you use, and why?

GB: Initially, we are using the Health Graph API to acquire up-to-date information from InsideTracker users via mobile apps. These apps are convenient for our customers, and the data we receive from them makes our analysis more timely.

BD: What do you like about the Health Graph? What would you like to see changed?

GB: The Health Graph platform is excellent because it integrates so many different products and applications. Our customers benefit from being able to share and track many aspects of their fitness and wellness data through Health Graph.

BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?

GB: In fact, the Health Graph team has already responded to our request to extend the Health Graph API to represent measurements of the biomarkers analyzed by InsideTracker! We plan to explore future extensions to InsideTracker in which users will be able to share their analysis data using the Health Graph API.

BD: Can you share any future plans for InsideTracker? What’s coming next that your customers will be excited about? Does the Health Graph play a role in that, and if so, how?

GB: InsideTracker is planning to integrate data from wireless scales so that we can update our recommendations for nutrition and exercise daily based on a customer’s weight. The Health Graph API is essential for us to integrate these data.

BD: Is there anything else we should know about you or InsideTracker?

GB: If you are looking for a roadmap to wellness and performance, get InsideTracker. You will find out where you are, where you should be, and how to get there by making changes in lifestyle, exercise, and nutrition. We turn measurements into meaningful advice.

is_live – boolean added to Fitness Activities to indicate whether the activity is currently being tracked via RunKeeper Live; note that this field will report ‘false‘ until at least one GPS point for the Live activity is received (this should occur immediately upon beginning the Live activity, but may be delayed up to several seconds if it takes longer than normal for GPS hardware to acquire a sufficient GPS signal).

userID – integer added to each team member entry from Street TeamGET /team response to allow developers to more easily access team member account details (assuming member has authorized the calling app).

past activities are now available in a summary form that is more conducive to bandwidth-constrained environments; search for ‘summary’ in the Fitness Activities docs to learn more.

blood markers – a number of additional markers have been added to the General Measurements portion of the Health Graph API; for the complete list of what’s now available, please refer to documentation for General Measurements and Diabetes portions of the API.

Some of the best Health Graph (@healthgraphapi) partnerapps are built to solve a developer’s own health and fitness issues. Case in point: Weighty, a free mobile app for quickly and easily tracking your weight and body fat percentage using the Health Graph. Weighty creator Frank Van Rest (@frankvanrest) talks about the problem he wanted to solve with his app, and how he went about creating it, below.

Bill Day: Please tell us about yourself and your work.

Frank Van Rest: I’m a Dutch mathematician who graduated in the summer of 2011. During my studies I founded a web development company. After graduation I was in need of a new goal, and getting a regular job wasn’t a great lookout after being an entrepreneur for eight years.

While traveling I decided to target doing a full Ironman triathlon in two years. I’ve always been a basketball player and couldn’t swim, so this was a challenge. But I’ve been in training for half a year now and am getting in quite good shape!

BD: What is the “elevator pitch” for why someone should use Weighty?

FVR: Weighty is a free iPhone app that makes it super easy to submit your weight and fat percentage to the Health Graph. Tracking your weight is a key step to effectively losing (or gaining) weight. I hope Weighty makes this easy and simple for everyone.

BD: How did you get started using the Health Graph API?

FVR: As I’ve gone about my triathlon training, I wanted to add my weight and fat percentage to the same place as my activities. This was previously only possible via the RunKeeper website, which is not as easily accessible as a mobile app when I’m standing on my weight scale.

The Health Graph API made it easy for me to create such a mobile app myself! I started with the iOS library I found on github and got it (after some debugging) to working pretty quickly. (Editor’s note: A complete listing of available third-party Health Graph libraries is available by clicking here.)

BD: How is using the Health Graph benefiting you?

FVR: The Health Graph makes it easy to create apps that submit data to a central health-related data repository. This cloud-based approach is very valuable for users, since combined analyses can be done. RunKeeper provides free publicity for my app by highlighting it in the Health Graph app directory and showing it in users’ FitnessFeeds when they submit their weight or fat percentage to the Health Graph.

BD: Which portions of the Health Graph API do you use, and why?

FVR: After authentication, I only use the API calls to POSTweight and fat percentage. In the future I want to add historical data to the app, at which point I’ll also use GET calls to read that data back from the Health Graph.

BD: What do you like about the Health Graph? What would you like to see changed?

FVR: I like the ease of use of the API. I got a working version up and ready to test in a few hours of work.

During testing I found some small bugs in the API, but the API team fixed it quickly after contact. I’d like additional capabilities to remove and edit data records as well.

BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?

FVR: My scale also gives water percentage and muscle percentage, which I would love to keep track of as well. If that were possible with the Health Graph as well, I’d implement in Weighty!

BD: Can you share any future plans for Weighty? What’s coming next that your users will be excited about? Does the Health Graph play a role in that, and if so, how?

FVR: Removing or editing weight or fat percentage records is not possible at the moment (not on the RunKeeper website and not via the Health Graph API). If a user makes a typo and enters the wrong data, it can really mess up their graphs and weekly averages. I would love to have the ability to remove records via my app (or the website). As soon as that’s possible, I’ll add historical data to the app, with the possibility to edit and delete that data as well.

BD: Is there anything else we should know about you or your application?

This console gives you a quick way to try various Health Graph API (@healthgraphapi) calls. You can specify all the request details, submit your request, and then see the results that are returned by the Health Graph platform.

To start using the console, you need to connect it to a Health Graph account. Follow these steps:

Login to a RunKeeper/Health Graph development account. If you have registered one or more apps in the Partner Portal, you may wish to use that account. Note that we strongly recommend that development accounts not be team member personal accounts, since as part of development you will likely be updating and/or deleting data.

If you need to populate your development account with some test data before you begin making API calls, click here for several methods for doing that.

Authorize the console to connect with your development account (this uses the same OAuth-based authorization mechanism that other Health Graph partner apps use).

Once you’ve successfully connected your account, you should see a console window showing all the request options that you can specify.

As you can see above, the default request values are for a request to GET your connected account’s /user resource. /user is the initial entry point for accessing any given user’s Health Graph account data. If you submit the default request, the Health Graph platform will send back the /user resource information corresponding to the specified access (“bearer”) token, in this case one of my test development accounts.

You can pass any valid Health Graph request in via the console. For instance, we can use the /user response to see what additional resources are available for this user, pick the /fitnessActivities resource, and then make a GET request to read the fitness feed.

If you’ve correctly specified your request, the Health Graph will respond with something similar to the following.

If you make an incorrect request, for instance by specifying the wrong content type that you’d accept back:

then you’ll receive an error response:

Note that the console supports using a */* wildcard for the Accept header content-type value. This enables you to make a request without knowing in advance what content type you’ll receive back in the response. This is particularly useful when you are exploring and learning the API, as you can note the content-type in the response so that will you know the correct value to use when creating your own application.

However you get to a correct request, once you have its response back, you can use the details to continue accessing and processing Health Graph data. That’s all there is to it!

For a quick overview of what Health Graph API operations are available, you may wish to read through this “Health Graph Hacking 101” presentation. For more details on the various resources available to GET, PUT, and POST to as part of the Health Graph API, please refer to the full Health Graph API documentation.

We hope this console proves useful as you explore and prototype with the Health Graph API. And we’d greatly appreciate any feedback you have for how we can make the console even better.