November updates

Even more integrations, more user-friendly authentication, and additional data samples from existing integrations.

New integrations! 🔌

What?

We've added integrations with Biostrap, RideWithGPS, and InBody this month! Bringing our range of integrations to an even more extensive breadth, and depth. RideWithGPS adds to our cycling-focused integrations, InBody to our body measurement ones, and Biostrap to our more clinically-driven device integrations

How?

We've been in touch with Biostrap over the past year as they were developing their API, and have been excited to finally get to work with it and provide it as an integration now that they're more ready to release that!

As for InBody, we've also been in touch with InBody over the past couple of months, planning the best way to add them into our system due to their authentication-less system for querying data 😺 instead, each facility has its users & identifies them internally, and can fetch their data at any point.

For RideWithGPS, this was a standard OAuth2-based integration that fits right into the current ones such as Wahoo, Garmin, Zwift & the like in terms of the data types returned.

Why?

We're always looking at expanding the number of integrations we offer. Being a one-to-all API is a core driver of our main product, and this goes in that exact direction. For some of these integrations, our users have been requesting them and been excited to use them; for others we need to reach out to form partnerships & proactively plan ahead.

User-friendly authentication

What?

Until now, our authentication mechanism has been developer-focused. We made sure that all users connecting through the service would need to share all possible data points requested by the developer to be successfully authenticated.

If all the boxes aren't ticked, the authentication will be unsuccessful.

Instead, we now can allow users to restrict the range of data they consent to share with developers, and instead let developers know the scopes they have agreed to share.

How?

We changed our authentication mechanism to be more permissive, and keep track of the user's accepted scopes at any given moment. This allows us to also return the scopes in the Terra User object as metadata for debug purposes and lets users keep utilizing the various functionalities of developers' apps that they have access to

Why?

While this meant that developers would never be left wondering why a certain user wouldn't receive e.g. heart rate data but would receive the rest, it meant that users who don't want to share the entirety of this data with a developer wouldn't be able to use their app, causing potential frustration.

We were now confident that at this stage, as our systems have become a lot more robust & confusion has been reduced as to why certain data may not show up for a given user, UX should take priority, and focus should be placed on making connection as smooth as possible for end users.

Additional data samples

What?

We've added calorie samples, duration data to these and step samples and allowed Coros activities to provide sample data as often as second-by-second.

How?

For calorie & step samples, it's now possible to retrieve how long it took a user to accomplish those steps thanks to the timer_duration_seconds field, which in the Daily payload, indicates the time elapsed between the start of the very first sample in the area until the end of the current sample.

Combined with the sample's timestamp, which indicates the start time, it is possible to deduce how long the user took to burn a certain amount of calories or walk a certain amount of steps.

Coros has always provided FIT files in a non-standard format, which all available FIT parsers out there for Python could not parse. Recently, however, Garmin (who owns the FIT standard) released a Python version of their official SDK in early October, which was able to decode Coros fit files (even though it issues a warning letting us know that the FIT file is technically invalid)

Why?

Coros has been gaining popularity over the recent past, and users wanted to be able to access more granular data coming from activities recorded with their watches. To this effect, combined with the fact that Garmin released their newest SDK promptly, we wanted to implement this feature ASAP to fully use Coros' data!