Product logo

Strava

Advanced

The content of this article is aimed at users who are familiar with our platform and have some technical knowledge.

It probably needs no introduction, but Strava is one of the most popular applications among riders to record their activities and share them with their community.

Integration with Strava is done through a Strava application. A Strava application is simply an add-on that any user can authorize to enhance their experience.

When a workshop registers a rider on our platform, we create a Strava application authorization request on behalf of the rider. Thus, when the rider accepts the invitation, they are authorizing us to access information about their bikes and rides. It's important to note that we are the information manager at all times, not the workshop. This way, if a rider decides to leave the platform or revoke a workshop's access, that workshop can no longer access their information.

Authorization Flow

This is the authorization flow with Strava:

A workshop registers a rider

Let's assume the rider doesn't exist on our platform yet. The workshop creates an account for the rider and enters their preferred sports app (in this case, Strava). Next, a link is generated through which the rider authorizes us to access their information.

The rider is notified

The rider receives a notification informing them that their workshop has registered them in sincrona and requests to follow their maintenance.

The rider authorizes the application

Once the rider follows the instructions in the notification, we create their account on our platform.

In parallel, we create a rider-workshop relationship, which will allow the mechanic to see the information about the rider's bikes and contact details.

If they don't authorize

If the rider decides not to authorize, or simply ignores the notification, after a reasonable time we will proceed to delete any trace of their registration.

Access to information

All information from Strava will be managed by sincrona. The workshop will only have access to the rider's bikes and rides information when they have previously authorized access.

If the rider denies access to their workshop, or changes workshops, their data will remain on the platform. The only thing that will change is the rider-workshop relationship.

Synchronization Process

Below is the process for ingesting information from Strava in the main use cases.

What we keep from each ride

From each ride we keep its date, distance, moving time, sport and elevation gain, and whether it was a commute or on an indoor trainer, as Strava reports it (a virtual ride always counts as indoors). We use them to work out each bike's wear and your workshop's analytics.

Initial synchronization

This only happens when the rider accepts authorization for the first time. Here:

  • We map the bikes defined in Strava.
  • We collect the rides associated with each bike.
  • All rides that took place before a safety period will be assumed confirmed and recorded.
  • We update component wear values based on recorded rides.

Real-time synchronization

When a rider records a new ride, Strava notifies us, then:

  • We obtain the details of the ride and the bike used.
  • We save a provisional version of the ride without affecting wear values.
  • After a safety period (2 to 3 days):
    • We check for possible modifications to the ride (bike changes).
    • We update component wear values.
    • We mark the ride as confirmed.

Periodic synchronization

Periodically we check if there are new rides, regardless of whether we save the data in real time. The reason for doing this is to make sure we don't miss any rides in case Strava hasn't notified us correctly, or we couldn't process it at the time due to some temporary failure.

Activity updates or deletion

When a rider deletes an activity, Strava notifies us and we delete the ride on our platform. If it was already confirmed, we take its distance and time off the bike's wear.

Strava doesn't notify us when the rider changes an activity's bike, so we only check the bike once, at the end of the safety period:

  • If the rider changes the bike during those days, the ride moves to the right bike when it's confirmed.
  • Once the ride is confirmed, we no longer check it for changes. To move it to another bike, the rider has to delete the activity in Strava and upload it again with the right bike.

When access stops working

If Strava stops accepting our access to a rider's data, we mark their connection as broken. We spot it in three cases:

  • The rider removes sincrona's access in their Strava settings. Strava tells us straight away.
  • Strava rejects the renewal of the permission.
  • Strava keeps rejecting our requests even after renewing it.

While the connection is broken:

  • We don't import new rides, and the periodic synchronization skips that connection.
  • Provisional rides aren't confirmed: they wait, without affecting wear values.

Each time a connection breaks, we send the rider one notification on the channel they chose (email or WhatsApp), and don't repeat it while it stays broken. The workshop isn't notified.

The rider sees their connection's status on their profile and repairs it from there, by authorizing the application again with the same Strava account (see check and repair your connection). We then fetch the rides recorded since the last synchronization in the background, and process them just like in the initial synchronization.

On this page