How peakat handles Strava data

Each hiker has three records in Redis. A seven-day cache holds everything read from the Strava API: the hiker's name and photo, the summits detected in their activities, and for each activity that reached a summit its name, distance, moving time, elevation gain and summary polyline. Activities that reached no summit are not cached; the operator's event log notes only that a webhook arrived for them.

An account record holds the account's own id, the Strava athlete id with its tokens and the scope the hiker granted, the email address the hiker signs in with, if any, when they were last seen, their preferences, the ids of badges already celebrated so none is announced twice, and any celebration or lost-badge notice waiting for the hiker's next visit, removed once shown.

A hiker may also import complete track files into private Vercel Blob storage, kept until explicit activity/account deletion. This archive is independent of the Strava API and is never populated from its transient cache. The derived activity record contains the summits detected and, per outing, its start time, distance, moving time and elevation gain, plus a simplified route spanning the whole activity, including its start and finish. The complete route is shown in the hiker's private view and may appear in a video they export themselves; public share links crop the first and last kilometre on the server.

Page views are counted by Vercel Web Analytics: the page's path with its query string removed before it leaves the browser, the referrer, the country, and the device and browser type. It sets no cookies and keeps no IP address, identifying a visit by a hash of the request that is discarded after 24 hours. No Strava data is sent to it.

The cache key has a TTL of 604,800 seconds, set when the history is fetched from Strava. A webhook update merges a single activity without resetting it, so the clock runs from the fetch, not from the latest write. When it expires the data is gone.

Before it expires the cache is replaced, never extended: the same full read is made again, and the new copy has a new 604,800 seconds counted from that read. This happens only for a hiker who is using the app, and at most about once a week. A daily job re-reads caches that are at least 5 days 20 hours old, for hikers who opened the app within the last 30 days, a few at a time and spaced out; a hiker who opens the app with a cache six days old that was not yet re-read has it re-read in the background; and a webhook for a new or edited activity that arrives when the cache has already expired reads the history first, once, and then merges the activity. A hiker who stays away for more than 30 days and sends no activity is not re-read, and the data expires after seven days. A webhook against a warm cache never re-reads and never extends the clock, and no webhook counts as the hiker having opened the app.

Account identity, sign-in ownership and independent imported outings have no inactivity expiry. Provider access credentials have their own lifetime of up to 365 days from storage or renewal; background COROS sync preserves that expiry. Retaining identity never extends the Strava cache. The operator's event log is kept in one key per day, each expiring seven days after that day began.

From Compte, a hiker deletes their account in one step. We revoke the app's Strava authorization, delete its activities, credentials and ownership indexes, and show whether the revocation reached Strava. A deletion marker linked to the old internal account UUID remains, without expiry, so pending work cannot recreate it; this marker holds no email, provider identifier or activity.

When Strava reports that a hiker deauthorized the app, its access credentials and cached API data are deleted as the event is processed. The account, stable sign-in ownership and independent imported or COROS outings remain, including for an account without email. Signing in through Strava again requires a new authorisation; the retained identity cannot access its API. A token that Strava refuses to refresh is handled the same way. When an activity is deleted on Strava, its summits leave the cache on the same webhook, and an edited activity is read again and re-detected.

We request activity:read_all, to detect summits in the hiker's activities, and activity:write. Strava's consent screen lets the hiker grant or refuse each one separately. We store the scope Strava reports as granted, never the scope we asked for, and a switch in Compte lets the hiker turn writing off at any time.

When write is granted and the hiker's own switch in Compte is on, a newly created activity that reaches a summit gets one line per summit appended to the hiker's own description — never replacing it, never touching name, type or gear — naming the summit and, on a first ascent, which number it is in the hiker's own Repte, or on a repeat how many times the hiker has reached it, plus https://peakat.app. We keep no record of what we wrote: the link in the description is the only marker, so a hiker who deletes it stays deleted. This is why the write happens only on create and never on update — Strava fires update for an ordinary edit like a title change, and without a stored marker an update-triggered write would put a deleted block back.