Peloton & Qlik - How It Works: APIs, Python and a QlikDork

By David Freriks, Emerging Technology Evangelist / Partner Engineering at Qlik

Thanks for all those who enthusiastically responded to my first blog post on Qlik analytics with Peloton! 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 is a wizard with APIs, REST, Python and coding cool stuff. He has built an engine that serves as a broker for our AI/ML integrations 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 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.

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,” which 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

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 APIs and load them into 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 mother lode! 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. With a trained eye for visual acuity, I asked Dalton to help me build out the Qlik app we saw in my first blog post about Peloton. 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. But, because 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 APIs, 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 usernames/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 this blog post. There will be another one 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!

You learned learn how @dlfreriks used #Qlik Sense to analyze his exercise performance in his first blog post; now learn how he created the app


In this article:

Keep up with the latest insights to drive the most value from your data.

Get ready to transform your entire business with data.

Follow Qlik