Introducing developers.strava.com

In January of 2014, Strava launched the third version of its public API. Our API was originally intended to support our internal development team as a mean to power our own applications — all of the data presented in the Strava mobile applications channel through it.

The goals of the v3 API were to provide a consistent surface across a number of use cases, to give athletes control over their data and commit to a higher degree of privacy by implementing the OAuth protocol.

Since then, the availability of Strava’s public API has enabled a thriving ecosystem of applications used every day by millions of athletes. As of today, the number of applications clocks in at over 20,000 and the diversity of use cases has amazed us: from data importers to surfacing activity data on social networks, from advanced performance analysis to powering charitable initiatives.

Developers have gone well beyond the scope of what we intended, which is a great problem to have.

Over the years, working with the API has however become more complicated, both for Strava engineers but also for third parties:

• The numbers of endpoints and richness of the payloads has considerably grown over the years, and the documentation has become out of date.
• To support developers, we run a Google Group manned by a number of Strava engineers — this has been great for requesting access to web hooks or quota increases, but that channel offers little in the way of reporting and tracking the resolution of issues and feature requests.
• Finally, a number of developers worked and shipped third-party API clients in a number of languages. Such clients may go out of date just as the documentation does, and they also may not be fit for the needs of people working in arcane or brand new frameworks.

Today, we want to renew our commitment to support third-party developers by announcing the beta version of developers.strava.com. This new website seeks to consolidate the content from our Labs page and the documentation for the v3 API currently hosted on GitHub Pages. An additional goal is to remedy the issues mentioned above, and to power the next generation of applications developed on top of the Strava platform.

As part of this launch, we are publishing an OpenAPI description of the Strava v3 API (a.k.a. Swagger). By describing the API endpoints and payloads in a neutral format, the tooling provided by Swagger enables us to perform a number of tasks in a more scalable and less error-prone fashion, and opens up a number of opportunities:

• The new documentation page is automatically generated from the Swagger description, which means it is kept up to date, always.
• The new API playground, where developers can toy with production endpoints from their browsers and rapidly prototype.
• Swagger Codegen supports the automatic generation of API clients in over 50 programming languages.

Generating a client for the Strava API is as simple as pointing swagger-codegen to our canonical specification:

swagger-codegen generate -i https://developers.strava.com/swagger/swagger.json -l java -o my-cool-strava-api-client

Finally, this new website comes along with a new GitHub repository which hosts the source content of the website, including the entire OpenAPI definition. This repository is open to all and we welcome contributions, bug reports and feature requests.

Of important note: this site is still in beta and so is the OpenAPI specification that comes with it. We would like for developers to play with it, but we anticipate it to be a little rough around the edges. Some endpoints are absent from the description, certain fields might be missing or inaccurately documented, models might be changing names or be refactored— we are actively working on fixing these shortcomings, but we also wanted to have feedback from the community before aiming to release a 1.0 version.

Building rich applications on top of Strava has never been easier and we are eager to see what developers will invent and create using this tooling.