Peloton & Qlik Blog - Part 2 (How it works: API's, Python, and a QlikDork)

Thanks for all those who enthusiastically responded to my first article on Qlik analytics with Peloton (https://www.dhirubhai.net/pulse/peloton-qlik-blog-part-1-analytics-all-david-freriks)! Now onward brave souls as we learn HOW I was able to create the analytics I wrote about earlier.

First, you need smart friends. I am fortunate to be on the Partner Engineering team here at Qlik that has some of the best and brightest minds in Qlik. John Park (jpark328) is a wizard with API's, REST, python, and coding cool stuff. He has built an engine that serves as a broker for our AI/ML integrations (https://www.qlik.com/blog/democratizing-machine-learning-capabilities-with-qlik-sense-and-amazon-sagemaker) that allows communications with engines like AWS Sagemaker, AzureML, and DataRobot but also is adaptable to brokering communications with odd or difficult data sources using languages like python.

And that is where the journey starts.

Peloton, great company, awesome bikes - but well documented and easily consumable data by their users, not so much.

But, they they do have an API. Well, they kind of have an API… It’s mostly undocumented. There are a few folks who have done their best to expose what they’ve discovered, and that’s where our first step begins.

https://github.com/geudrik/peloton-client-library/blob/master/API_DOCS.md

https://app.swaggerhub.com/apis/DovOps/peloton-unofficial-api/0.2.3#/

So, where do we start to establish some baseline of connectivity, and what can we even get access to?

The first step is to learn how to access the Peloton API. There are a bunch of public API endpoints around classes and instructors which are interesting, but I need MY personal metrics. In order to access that data, we have to start by getting authenticated. That requires a POST REST call that returns a cookie “peloton_session_id” that is our token to entry going forward. It’s a simple call with credentials:

With our session token we can now start asking deeper personal questions. However, here is where we ran across a challenge that forced us down the Qlik Rapid API Gateway (QRAG) path. 

Qlik Sense has no method of capturing a cookie/session token for subsequent API calls, so we needed a brokering engine to capture and issue the API calls we needed going forward. Let’s talk about what QRAG offers…

• Bi-directional data movement from Qlik to 3rd party engines (Amazon Sagemaker, Azure Cognitive Services, Databricks, etc)
• Execute Python code to connect to 3rd Party API's
• Execute Python code to run popular Python libraries
• Single codebase deployed and maintained via GitHub

In a nutshell, QRAG is a data translator that allows Qlik to talk to ALL things in different protocols!

With the QRAG engine in place, we can now start using python to query and format the response from the Peloton API. QRAG is designed modularly and that's why John Park was able to create a module for us connecting to Peloton. John’s QRAG Engine runs on a Linux box as a service now giving us capabilities to pull from Peloton API’s and load to Qlik's in-memory engine.

First API call returns the data I need for some highlights:

This QRAG API brings back our workout details and all the connected supporting details. Tables we get that provide value are called with this API are:

·     Instructors Information (not all, just the ones I’ve used)

·     Workout Information (not all, just the ones I’ve used)

·     My Data for my workouts that tie in with the two above tables

However, the only real metric I get with this data set is the “total_work” which is the kJ I exerted during the workout. That is great info, but not the complete set of metrics I want.

To get deeper, I need one final API call to get the workout details.

Aha – the motherload! Cadence, Heart Rate, Power, Resistance, Calories, Distance, Max Metrics… etc. This is the color I’m really looking for to track my overall health!

Cleaning up the REST calls a bit – we now have our data model we can use to start our analytics.

John's QRAG engine works like a champ. We have defeated the Peloton API and have the data we want!

Now, what's the best way to visualize it? How do we make it accessible to others? How do we protect user data? Can we make it look really cool?

Enter the QlikDork, Dalton Ruer (https://www.dhirubhai.net/in/daltonruer/). With a trained eye for visual acuity, I asked Dalton to help me build out the Qlik app we saw in Part 1 of the blog. Of course, since he knows everyone - he had a Doctor come give us recommendations of the types of metrics to start with (very cool).

I went ahead and built the initial application showcased in the first article, but so many of you reached out about accessing your own data, we decided to architect a version that would be open to the public using John's engine, and Dalton's design skills.

So introducing Peloton App V2. Leveraging the power of the Qlik Sense platform and internal API's, we are able to create a version where any user can access their Peloton in a "session" app that does not persist user data or user name/passwords.

You just enter your data, the QRAG engine executes the API data pull, the Qlik App reloads and like magic your stats are available to analyze. As soon as you close the browser, the data and the app are discarded from memory as the session is terminated.

And yes, I did do my first 75 minute ride and I'm still sore...

So, that wraps up part 2 of the blog... There will be a part 3 coming out soon with QlikDork (aka Dalton Ruer) on how we adapted this data into a webapp using Qlik's mashup capabilities.

If you'd like to test drive the app with your data (currently limited to your last 1000 exercises while we test) - please reach out to me on LinkedIn and I'll get you access and some basic instructions.

Keep on riding folks!