I find it amusing that some of my cycling friends have just discovered Strava, right at a point when I’m looking to leave. When they ask why, I cite Strava’s recent decision to shutdown API access to all but a select few app vendors. I had an inkling why access to the new API was limited, and I’ve confirmed it. Now I’d like to explain the correct way to do it, and how to monetize it at the same time.

Strava API the wrong way

I had a suspicion that no open source projects would be able to use the new Strava API, and I was right. All you have to do is read this one sentence at the top of the new V3 API documentation:

All developers need to register their application before getting started. A registered application will be assigned a Client ID and Client SECRET. The SECRET should never be shared.

This is a broken model. Essentially app developers need to get approved for access and then they’ll embed their OAuth secret in their code, which will be sent to Strava to authenticate before making any calls.

This. is. wrong.

Besides being a bad approach, it leaves out all open source applications because they can’t simply put that OAuth secret right in their code – it would be there for anyone to see (and use).

Strava API the right (Facebook/Twitter) way

Let’s take a look at how Facebook and Twitter handle app authorization. I know these guys aren’t exactly angels, but when it comes to web services API access, I think they have it right. When you use an open source application to connect to Facebook or Twitter, you as a user can set up and authorize an “app.” Think of an app in this case as more of an intermediary between you and Facebook / Twitter.

Here’s how it works: as an end-user, you set up an app on the Facebook or Twitter developer website. In exchange you get back the aforementioned Client ID and Client SECRET which are unique to you and the instance of your app. You put your Client ID and Client SECRET into your database (or wherever it goes) and since it is unique to you, it never needs to go anywhere in the code.

On Twitter the process can be almost fully automated and completed for you. You can have apps created and all you have to do is approve that they can access your Twitter stream, and then save the OAuth credentials it gives back.

This is a great model for open-source software. WordPress, software that powers over a billion websites, is open source, and you can install a plugin like Twitter Widget Pro which will display your Twitter stream on your website. This plugin automates as much as possible and walks you through the app setup and approval process.

To control (read: restrict) app access, Strava could easily add a 3rd identifier (I’ll call it App ID). Strava could have developers (not end-users) apply for an App ID. Based on their criteria, they could accept or reject those requests. The App ID could be public and exist in code – open source or not. Because you would need an approved App ID and a legitimate Client ID and Client SECRET to authenticate. Strava could block apps on occasion and still achieve widespread adoption.

Monetizing API Access

This is a no-brainer. If the system were re-worked to put the app and API access in the hands of users, Strava could simply make it only available to premium members. I’d gladly pay Strava $6 a month if they gave me back API access, plus it would help weed out anyone that would be abusing the system (although I’m still unclear on how someone would do that).

Also, you could still maintain the status-quo with the current V3 applications – they already have their Client ID and Client SECRET already set up.

One thought on “Strava API – You’re doing it wrong

  1. Pingback: Using QLandkarte GT for Strava - Justin Foell

Leave a Reply