How Trailboard technically uses the Strava API

1. Integration scope

Trailboard is an independent trail-race preparation tool. Connecting Strava is optional and is used to display transient copies of the athlete’s authorized activities and personal descriptive indicators in their private space.

Trailboard does not create, update, or delete activities on Strava. The application does not use Strava activities to build a public ranking between athletes.

The public scope submitted to Strava is limited to the uses described on this page. Any extension beyond these uses requires written confirmation from Strava before it is enabled for users.

2. OAuth authorization

• The connection button redirects the browser to the official Strava OAuth authorization screen.
• The scopes requested by the code are “read” and “activity:read_all”. The latter lets an athlete authorize access to private activities for their own Trailboard space.
• The OAuth callback validates a random, single-use state value against CSRF before exchanging the authorization code.
• New access-token and refresh-token writes use AES-256-GCM encryption in PostgreSQL. Secrets are never included in this public page or in frontend responses.

3. Strava data read and purpose

Trailboard requests only the resources used by its current personal features. The code has no permission to write Strava activities.

4. Webhooks and synchronization

• Trailboard exposes a public server callback for Strava events. The verification secret is never published.
• An activity create or update event enqueues a targeted refresh. A delete event enqueues local deletion. Athlete deauthorization enqueues removal of the connection and synchronized activities.
• Heavy processing is stored in a durable PostgreSQL job queue so that the callback can return quickly, retries are controlled, and a restart does not lose the event.
• No periodic Strava API polling runs. Calls originate only from initial import, an explicit user action, or a targeted webhook event.
• The production application webhook subscription is checked separately from the presence of callback code.

5. Rate-limit protection

• Dashboard reads serve PostgreSQL data first and do not make a blocking Strava request for every view.
• PostgreSQL locks prevent simultaneous synchronization for the same athlete or application.
• When Strava returns 429, Trailboard persists a cooldown for the affected application and defers jobs until the retry window.
• Explicit imports are bounded and stop when a limit is encountered.

6. Deauthorization and deletion

• A Strava deauthorization event cancels active synchronization jobs and removes the connection, Strava copies, and corresponding derived personal data.
• Deleting a Trailboard account removes the account and linked records transactionally, confirms deletion to the user, and durably records remote Strava token revocation.
• An activity deletion received by webhook removes the local copy owned by that athlete.
• Each Strava copy has its own retrieval timestamp and expires no later than seven days later, regardless of the activity date.

7. Security and isolation

• Every activity route checks the current Trailboard identity and filters data by athlete identifier.
• The repository encrypts new OAuth writes with AES-256-GCM and serializes token refreshes to prevent concurrent writes. Production must be checked separately to confirm that no legacy plaintext value remains.
• Callbacks and jobs carry a connection generation, so an old event cannot act on a newer reconnected account.
• Trailboard does not sell Strava data or use it for targeted advertising.