This morning’s announcement by Garmin of their Garmin Sync rollout is one that’s been long in the making – starting in earnest much earlier this year. The culmination of that effort arrived today with direct synchronization to TrainingPeaks and runcoach. But ultimately, those two companies are just the first two to take advantage of it – with a number of massive fitness/sports names in the queue, as Garmin and those other companies work through the technical implementation details.

A bit of background

So then you might be asking – why would this be a bad thing? Well, because while Garmin has built a bridge that many users will love with automatic sync, they’ve also built a huge wall at the same time. That wall was targeted at blocking the numerous app developers that used to directly pull data from Garmin Connect. In doing so Garmin effectively completed a Strava-like blockage on a single night without any notice (that they since changed direction on).

Up until February, Garmin Connect had an API that was available to developers to use free of charge. An API that was built over half a decade earlier by the MotionBased team (which Garmin bought and eventually rebranded Garmin Connect). The API had a very simple terms of service, that previously said (in total):

“You are free to access our API as long as you agree to create great things.”

Which, developers did. There were cool apps that uploaded data, parsed data, viewed data, and allowed you to analyze the data. Ultimately, they were allowing you to view your data that you uploaded.

When I first started poking around at this back in early January (before the data cutoff in February) when Garmin appeared to delete the welcome page for the API instructions (but not delete any other content, including all the details). When I queried they responded with:

“Garmin’s API is not open to anyone. We are working closely with B2B partners who are looking to use activity data to validate a participant’s activities in their wellness program. The API makes it possible for all activity monitoring and fitness device data to be shared with a wellness partner. You can find our corporate wellness page here, which will change on January 6 to reflect the new product announcements.”

I found this sorta strange given that they had an entire site dedicated to said API (still present even then), along with terms of service that still said you were allowed to do anything you wanted as long as it was great.

But things got quiet again and nobody screamed…until mid-February.

Garmin Connect Modern Rollout

Fast forward to the week of February 17th, when Garmin started rolling out their new Garmin Connect Modern interface, also known as GC2. This interface would be the long-term future of Garmin Connect for sports and fitness activities, but more pressingly was required to rollout Garmin Vivofit, their recently announced daily activity tracker. Since everything for Vivofit was built with GC2 in mind, and since it was time to start shipping Vivofit to consumers – Garmin began the rollout of GC2 to consumers.

In doing so however, they immediately broke all 3rd party application access to Garmin Connect. This meant that any 3rd party site or apps (mostly apps though) could no longer access data from the site. Apps like ConnectStats, LogMyTraining, RunCoach, Sport Tracks, Training Peaks, Wahoo Fitness, and Altifondo, among many others.

Ironically, apps like Sport Tracks & Training Peaks broke not because of the Garmin Connect rollout, but because of a concurrent start of the Garmin Express rollout (to replace the Garmin ANT Agent for uploading Garmin Forerunner workouts). The app without notice changed the location of the files, thus overnight breaking consumers ability to easily use those third party apps and forcing those companies to change their software.

After a flood of complaints I brought the API/site breakage issue up to Garmin, to which Garmin responded with:

“I spoke with our Connect team and it was unintentional and there is no new blocking policy. Any application developers that have run into an issue can contact us at [GC e-mail address] to let us know what isn’t working for them.”

So app developers did. They sent e-mail off to that address…and heard little back. One has to remember when you’re a developer and your app or site breaks that’s generally a life-altering event (just like it was for apps that depended on Strava when it broke).

From my side Garmin appeared to be somewhat interested in sorting out the problem. In talking with them later, they explained that they were rather surprised at the breakage. And that given all of the things they had on their plate to deal with that week during a major product rollout – breaking a bunch of apps was not on the agenda of ‘wants’.

To that end, I’d agree that I don’t think they purposefully broke it. But, I also think it’s somewhat naïve to not test at least a handful of 3rd party apps, given Garmin was aware of said apps beforehand (since some of them had been individually blocked).

But over the course of the next 5-7 days the messaging soon changed from Garmin. Gone was the friendly desire to help out these apps, but rather to start restricting them. Instead, the apps soon received information on their next steps from Garmin:

“The developer program will reply within 48 hours to the initial developer request to get the pertinent information. Once all of the information from the developer is received they will reply within approximately 24 hours either denying their request or providing the Terms of Use for execution. They will send an invoice (a $5000 one-time fee) about a week after the signed Terms of Use is received. When payment is received, the FTP information will be provided to obtain the API and token.”

So instead of having an open access policy, they would be charging the apps $5,000 to ‘play’, along with signing of a legal agreement. For most smaller apps, this would basically amount to killing the app.

The $5,000 Garmin Connect Access Program

So why put barriers in place? Well, you generally want some sort of gateway to control access to your platform. That’s totally reasonable. For example, Garmin noted that some apps had been so poorly coded as to essentially simulate a full on attack of the site while trying to pull data.

Most sites do this by implementing an API that allows authorization on both the 3rd party site/side as well as (in this case) the hosting platform side (i.e. Garmin Connect). Except, Garmin didn’t really have that level of granularity – putting them in a bit of a pickle.

Their API was ‘limited’ at best, and didn’t really have any controls in place to easily authorize a specific application. Adding fuel to the fire is that Garmin Connect never really responded to any such formal e-mail requests for such access from developers (many developers over the years had tried, and never received an answer). So they couldn’t easily weed out bad apps from good apps. In some ways, Garmin had made their own bed here.

So why the $5,000 fee? Well, that was essentially a ‘get off our lawn’ move. For most hobbyist developers and smaller companies, the $5,000 fee was an immediate roadblock. And for large companies (like Training Peaks), the money wasn’t the issue – but the time integrating the platform and the legal agreements that Garmin wanted companies to sign would be. Those would take months to sort out (as proven). Thus effectively Garmin effectively solved their problem.

Why closed access isn’t actually good for Garmin either

Lost in this entire debate is that consumers have lost easy access to their Garmin Connect activity data from other apps. So it used to be that I could easily access that data from a multitude of apps that showed and did cool things. For example analyzing and visualizing my Garmin activities in totally new and innovative ways. Sorta like what many of the Strava apps do today.

Garmin in turn argues that you can still access your data directly from your device. For example, you can plug in your new Edge 1000 and download directly from USB. And that’s absolutely true. The raw .FIT data is still there, and still accessible. And, you can still do that.

Except that’s not the direction consumers are moving to or wanting. If it was, then Garmin wouldn’t have worked with Training Peaks to work out automatic sync.

Rather, consumers want access to their data from any device they have. In the enterprise world that’s known as “Bring Your Own Device”, meaning that if you have an iPad you can connect to the service or platform. In the case of the Edge 1000 for example, you actually couldn’t use an iPad to access the raw data and send it to Strava (or some other site) since you can’t plug it in via USB to an iPad.

Garmin believes that they need to restrict access to the API with a $5,000 fee and lengthy paper legal agreements because it’ll cost them money if lots of developers start using their platform, with those costs split between human support costs and increased web hosting (server) costs.

Of course, neither of those two really hold water to anyone familiar with the business.

Looking at the hosting fees first, the cost of running the API portion of these servers is minuscule at best, especially in an elastic cloud environment. The load on the backend developer API piece simply isn’t there compared to the juggernaut that is Garmin Connect (actual user website).

From an API standpoint, large companies (Google, Microsoft, etc…) all offer API’s to a host of services: free. And tiny startups also do the same. As do competitors like Strava (these days), and even direct Garmin competitors like Suunto. Surely, if all of these providers can do so for free, then certainly Garmin can?

But, I’m somewhat reasonable in this. I think it’s perfectly fine for Garmin to instead offer a tiered approach. They could offer a free tier with lower API limits and limited support, and then a higher end tier with higher volumes and full support. This would solve all the issues at once. Unfortunately, Garmin doesn’t feel the same way here.

Garmin feels like these apps are in many ways competitors. Which is ultimately not at all the case, and an incredibly short-sighted view of things. These apps are actually strengthening the Garmin Connect platform. Taking Strava for example, with their API they allow developers to do ‘cool stuff’, and as such you see more people loading data into the platform – often to use 3rd party apps on their phones or browsers. This in turn serves to further tie people to a service.

For example, this app below to chart out rides from my activity files:

Virtually every one of these apps start as a hobbyist project first. It’s usually one person doing something they love that slowly grows into something more. Which is actually how virtually every company ever starts. If Garmin was smart about it, they can harness the power of these hobbyists/apps to show off the power of the Garmin device ecosystem – thus indirectly making it more appealing to buy Garmin devices than competitor devices. And as they grow, those apps could move up tiers in a Garmin Connect relationship – thus ensuring Garmin resources aren’t out of whack with demand.

Which ultimately would take them to where Training Peaks and soon others are today with Garmin Connect: A sweet sync service that consumers will love.

It’s just too bad that this new platform had to come at the expensive of a bunch of other just as cool apps and platforms.

Thanks for reading!