Posted by & filed under Velo Flow.

VeloFlow Needs YouAs most of you will know Strava is moving to a new and improved version of their API (the way I get all my data from Strava to populate VeloViewer) and I’m currently working on VeloViewer to use this new version of Strava’s API. In general we are all going to be very excited by what the new API will offer us and I’ll go into that very soon in another post, but there is one sad bit of news – the main API that drives VeloFlow will no longer be available 🙁 This will mean that I will not be able to get the list of rides to display and I can’t think of another way to do it. So, the only hope I can see to keep VeloFlow going is to get all you good people to vote up and comment on my request to save the API on the Strava support site to show Strava how much you all want to keep VeloFlow running.

Please visit my request to save the VeloFlow API on the Strava site and get voting (click the “Me too!” button) and commenting and we’ll see if the power of the people can make a difference!

Add comments on the request page rather than on this blog post. Ta!

Please note: This is only effecting the VeloFlow functionality on VeloViewer. The rest of VeloViewer will be improving immensely (QOM, runs, heart rates and much more) by using all the new goodies offered up by the new, improved Strava APIs. Strava have been very supportive of VeloViewer and this is made clear by them giving me early access to their new API.

Share

2 Responses to “Save the VeloFlow API!”

  1. Tom Bammann

    Is this the same API that raceshape.com uses? And didn’t they employ the guy from raceshape? So I’m guessing they intend on implementing the raceshape/veloflow type features within Strava, and don’t want anyone else to be able to. But the reality is that even if Strava was going to implement such a feature anyway, the early work done by yourself and others is critical to understanding more about what does and doesn’t work. If I were an important person behind STrava I would be recognising the success of the few people that have built such good 3rd party apps using Strava data. It’s not like you’re competing against them, you’re competing WITH them. People still need to upload to Strava to use VeloFlow and VeloViewer etc. So not only should they continue to allow you to use the API, they should be offering you a reward and even linking to veloviewer.com and raceshape.com and any other cool 3rd party apps, from somewhere within teh Strava website. Otherwise they’ll be going down the path that trainingpeaks.com went down – think that their stuff is so good (and it was) that there’s no need for any major overhaul for many years, then suddenly it’s a dinosaur. Oh that’s right, Strava are directly copying trainingpeaks.com from their performance management chart. Sorry I began ranting, but just wanted to say I support you and keep up your great work! Even if Strava don’t say so! 🙂

    • Ben

      I don’t think there is any kind of conspiracy that you might be eluding to. It is the same API as RaceShape uses but there still will be a V3 leaderboard API. The important bit as far as VeloFlow (and one of the options of RaceShape) is the filtering of the leaderboard by a date range and that is the bit that isn’t in the V3 API. The V3 leaderboard API allows filtering by a few things (this year, this month, this week and today along with gender, weight, age, club and following). I can completely see why they wouldn’t have planned to support this ad-hoc date range as the new API basically replicates the functionality in the website and mobile apps which don’t offer this functionality.

      You would hope that they could look at their server logs to see what options were being used on their current API’s and attempt to support them but the way software development works there is always a compromise of functionality based on the priority of each feature and the resource available to build it. Obviously features required by Strava’s own site and Apps will be more important than ones they don’t use.
      Hopefully this will just bump the requirement for the ad-hoc date range filtering up the development backlog a bit but that still doesn’t guarantee that it will be done. In my day job I work for a firm with far larger development products/projects than Strava and this prioritising feature requests always ends up with some people disappointed.