Strava API 2026: compliance, access review, and agent guardrails

Canonical BikeTrack policy for work involving Strava. Last verified against official Strava sources on 2026-07-24.

This is an engineering and product compliance guide, not legal advice. The current Strava API Agreement, API Policy, developer documentation, API Dashboard, and written instructions from Strava always take precedence.

Evidence labels used in this document

• CONFIRMED — STRAVA: stated in a current official Strava source listed in Official sources.
• BIKETRACK CONTROL: an internal product, security, or reliability gate. It is intentionally stricter or more specific than Strava's published wording and must not be presented as a verbatim Strava requirement.
• VERIFY — DASHBOARD/PRODUCTION: cannot be established from repository source or public documentation; verify it in the current API Settings Dashboard, review form, deployed environment, or production evidence.
• ASK STRAVA: the public documents do not resolve the point clearly enough for BikeTrack's use case. Obtain written clarification from [email protected] before relying on the interpretation in a review submission.

1. The decision in one page

Status: BIKETRACK CONTROL (product positioning based on confirmed Strava use restrictions).

BikeTrack should present its Strava integration as a narrow, private bicycle maintenance workflow:

• a user explicitly connects their own Strava account;
• BikeTrack reads only that user's cycling activities and bicycle gear;
• imported data is visible only to the authenticated owner;
• activity distance and gear can update that owner's private bicycle-maintenance records;
• BikeTrack's independent map and route-planning functionality does not depend on Strava Data;
• BikeTrack does not reproduce Strava's social feed, leaderboards, challenges, training analytics, or brand identity;
• BikeTrack does not sell, advertise against, disclose, aggregate, benchmark, or otherwise repurpose Strava Data;
• no real Strava Data or data derived from it is sent to an AI system, an agent, a prompt, a context window, an embedding service, RAG, or a model-evaluation pipeline.

The access path is:

Status: CONFIRMED — STRAVA. Capacities and published limits come from Rate Limits; tier definitions come from API Policy section 3.3.

Stage	Athlete capacity	Published limits	Action
Single Player Mode	1	Overall: 200/15 min and 2,000/day; read: 100/15 min and 1,000/day	Build and test only with the developer's account
Self-service access	10	Overall: 400/15 min and 4,000/day; read: 200/15 min and 2,000/day	Upgrade in the API Settings Dashboard
Reviewed multi-user access	More than 10	Assigned by Strava	Apply only after reaching 10 connected athletes and demonstrating real demand

A Strava subscription is currently a prerequisite for creating an API application. Strava's official Developer Program announcement made it required for new Standard Tier developers on 2026-06-01 and for existing active Standard Tier developers on 2026-06-30. Extended Access applications are generally exempt under the current API Policy.

Status: VERIFY — DASHBOARD. Do not hardcode a price in product documentation: the applicable subscription, price, payer, exemptions, and regional terms can change and must be checked in the API Settings Dashboard before submission. The API Agreement currently says API access itself is provided at no charge, while the API Policy separately makes Standard Tier subject to Strava subscription requirements. Do not describe an unverified subscription price as a “developer API fee.”

The 2026 API Policy defines Standard Tier levels of up to 10 and up to 9,999 registered users. Extended Access Tier generally applies at 10,000 or more users. Therefore, do not describe every request beyond 10 users as an “Extended Access Tier” request. State the honest 12-month user forecast and let Strava assign the appropriate tier.

Approval, capacity increases, rate-limit increases, and review time are all at Strava's discretion. There is no published review SLA and no guarantee of approval.

2. Non-negotiable product rules

2.1 Purpose and product positioning

Status: CONFIRMED — STRAVA for purpose-limited use, no competing/imitating application, no proxy/aggregator, no API-specific end-user charge, and renewed notice/consent when collected data changes. The preferred BikeTrack description is a BIKETRACK CONTROL, not text supplied or pre-approved by Strava.

The registered purpose must match the shipped behavior. BikeTrack's preferred description is “private bicycle maintenance based on the authenticated athlete's own rides and gear.” Any new use of Strava Data requires a policy review and, if it changes the data collected or scopes requested, renewed user notice and consent.

Do not use Strava Data to:

• build a competing or imitative Strava experience;
• create social feeds, leaderboards, cross-user comparisons, challenges, or public athlete pages;
• power BikeTrack's general route planner, map intelligence, or product analytics;
• benchmark Strava, monitor its performance, or create a substitute API;
• create a pass-through proxy, aggregator, MCP server, agent interface, or integration platform;
• sell access to API-derived functionality or charge specifically for access to Strava API materials. Charging for independent, non-duplicative BikeTrack functionality requires a separate product/legal review.

2.2 Owner-only display

Status: CONFIRMED — STRAVA under API Policy section 2.3. The implementation controls below are BikeTrack's enforcement of that rule.

Strava Data supplied by athlete A may be displayed only to athlete A after authentication. “Public on Strava” does not make the data public inside BikeTrack.

Required controls:

• every query for activities, gear, routes, and derived maintenance data is scoped by the authenticated BikeTrack user;
• no shared route, public link, admin screen, support screenshot, telemetry dashboard, or export may reveal another athlete's Strava Data;
• test fixtures are synthetic and cannot be copied from a real athlete response;
• support staff and developers use metadata and redacted diagnostics, not activity payloads.

2.3 AI and agent firewall

Status: CONFIRMED — STRAVA for the AI/ML, context-window, embedding, RAG, and unauthorized agent-interface prohibition. The concrete repository boundaries below are BIKETRACK CONTROLS.

The 2026 API Policy prohibits using Strava API materials or Strava Data, including derived, aggregated, anonymized, or de-identified data, in the development or operation of an AI application. The prohibition explicitly includes prompts, context windows, working memory, training, evaluation, grounding, embeddings, and RAG. The only stated exception is the first-party Strava MCP for a subscriber's personal use; that exception does not authorize BikeTrack to expose a commercial agent interface.

For BikeTrack this means:

• Gemini surface classification and every future AI feature must be separated from Strava ingestion by an explicit data-flow boundary;
• no Strava activity, polyline, coordinate, timestamp, gear, athlete identifier, maintenance value derived from a Strava ride, API response, database row, log, screenshot, or production incident payload may enter an AI request;
• coding agents may work on source code and synthetic fixtures only;
• production database dumps and raw logs must never be attached to an agent task;
• “transient,” “not stored,” “anonymized,” and “only for the same user” are not exceptions.

2.4 No aggregation, analytics, or bulk dataset

Status: CONFIRMED — STRAVA under API Policy sections 5.4, 5.5, and 5.7.

Do not use Strava Data or anything derived from it—even if aggregated, de-identified, anonymized, or publicly visible—for analytics, customer insights, product improvement, or another customer's use. Do not combine it with other customer data for those purposes. Do not scrape Strava or accumulate repeated API responses into a corpus, archive, cross-user dataset, or persistent index beyond the operational scope and permitted transient cache.

BikeTrack analytics may record synthetic operational metadata such as request count, latency, HTTP status class, queue depth, and quota remaining only when it cannot identify an athlete or reconstruct Strava Data. Any new analytics field requires a Strava data-lineage review.

3. Consent, OAuth, and credentials

Status: CONFIRMED — STRAVA for the required consent disclosures, returned-scope validation, Bearer authentication, token confidentiality, token refresh behavior, and deauthorization dates.

Before OAuth, the UI and Privacy Policy must clearly explain:

1. which data is collected;
2. how it is collected;
3. why BikeTrack uses it;
4. how the user can withdraw consent;
5. how the user can request deletion;
6. how successful deletion is confirmed.

The application must also let a user request access to data they generated that BikeTrack collected through the Strava API. If BikeTrack collects contact information, the collection flow must let the user express contact preferences through notice and consent.

BikeTrack's current intended scopes are:

read,activity:read_all

Status: BIKETRACK CONTROL + VERIFY — PRODUCTION. Strava does not publish this exact pair as universally mandatory. It is the minimum pair selected for BikeTrack's current gear and private-activity workflow. Verify both the production authorization URL and the scopes actually granted by the review account.

read is used for the authenticated athlete and bicycle gear. activity:read_all is used for the owner's activities, including privacy changes delivered through webhooks. Do not add profile:read_all, activity:write, or another scope without a documented product need, a policy review, updated consent copy, and tests that verify the granted scopes returned by Strava.

BikeTrack security controls:

• use Authorization Code OAuth and a cryptographically random, single-use, expiring state;
• verify the exact scopes returned by the token exchange because the user can decline scopes;
• send resource access tokens only as Authorization: Bearer <access_token>;
• keep the client secret, webhook verification token, webhook signing secret, access tokens, and refresh tokens server-side;
• encrypt OAuth tokens at rest and redact them from logs, errors, traces, support tools, screenshots, and analytics;
• persist the newest refresh token returned by every refresh;
• treat access tokens as short-lived: the current authentication documentation states that they expire six hours after creation;
• use POST https://www.strava.com/oauth/revoke for disconnect. It is recommended now and becomes the only supported deauthorization endpoint on 2027-06-01;
• local deletion must still complete and be reported if the upstream revoke call temporarily fails. The failed upstream revoke must be retried and alerted.

The single-use/expiring state, encryption-at-rest, log redaction, and retry after an upstream revoke failure are BIKETRACK CONTROLS. They are not quoted as specific implementation mandates in the public Strava authentication page, though they support the Agreement's confidentiality and security obligations.

4. Webhooks, privacy changes, and reliability

Polling for new activities is not an acceptable scaling strategy. Use the Webhook Events API.

Status: CONFIRMED — STRAVA:

• one Strava application may have only one webhook subscription;
• validate hub.mode, compare hub.verify_token using a secret value, and echo hub.challenge as JSON;
• acknowledge valid POST events with HTTP 200 within two seconds;
• perform additional processing asynchronously;
• handle the documented activity and athlete event types and respect privacy.

Status: BIKETRACK CONTROL:

• verify X-Strava-Signature against the exact raw request body and reject stale or invalid signatures. Strava's current official webhook example demonstrates this pattern and a five-minute replay window, but the main Webhook Events API page does not separately state it as a universal normative requirement;
• durably persist the event before acknowledging it;
• make processing idempotent by subscription/event identity and by (bike_id, strava_activity_id);
• retry transient failures with bounded exponential backoff and maintain a dead-letter/failed-event alert;
• process activity create, update, delete, privacy-change, and athlete deauthorization events;
• never mark an event processed merely because no synchronous work was attempted; its required privacy effect must be complete or durably queued.

Cloud Run may stop CPU after a response and instances may disappear. A detached Promise is not a durable worker. Use a persistent queue/worker mechanism or a scheduled retry processor for PENDING and retryable FAILED rows.

5. Rate limits and backfills

Status: CONFIRMED — STRAVA for the header names, published limits, reset boundaries, 429 behavior, and the recommendation to replace activity polling with webhooks and throttle backfills.

Every Strava API response must be inspected for:

X-RateLimit-Limit
X-RateLimit-Usage
X-ReadRateLimit-Limit
X-ReadRateLimit-Usage

BikeTrack operating controls:

• stop or delay backfills before either short-term or daily capacity is exhausted;
• on HTTP 429, do not retry in a tight loop;
• use bounded exponential backoff with jitter and the next known reset boundary;
• short-term windows reset at 00, 15, 30, and 45 minutes past the hour;
• daily limits reset at 00:00 UTC;
• requests rejected for violating the 15-minute limit still count toward the daily limit;
• prioritize interactive user actions, deletion, and privacy events over history backfills;
• expose quota pressure, queue depth, oldest pending event, failures, and deletion latency in operations monitoring without logging Strava Data.

Prioritization, jitter policy, safety margin, and observability fields are BIKETRACK CONTROLS; Strava does not prescribe those exact algorithms.

Strava states that when an application has fewer than 100 users, rate-limit pressure is most likely caused by inefficient API use; its named examples are activity polling and an unthrottled backfill. For a small BikeTrack deployment, fix those causes and provide request-per-athlete evidence before asking for more quota.

6. Retention and deletion

Status: CONFIRMED — STRAVA for the seven-day Strava Data cache limit, immediate removal of an unavailable resource, reflection of user deletions within 48 hours, deletion after request/revocation/account deletion, the 30-day outer limit, deletion certification, and the ban on persistent indexes.

Maintain a field-level data inventory that classifies every stored value as:

• OAuth secret/credential;
• raw Strava Data;
• personal data derived from Strava Data;
• user-authored BikeTrack data;
• synthetic operational metadata.

Minimum policy:

• raw Strava cache lifetime is at most seven days;
• if a resource is no longer available from Strava, remove it immediately;
• reflect a user's deletion from Strava expeditiously and no later than 48 hours;
• on user request, Strava revocation, or deletion of the Strava account, permanently delete that user's Strava Data and personal data derived from it;
• complete full deletion expeditiously and no later than 30 days; BikeTrack's product target is immediate deletion;
• provide written, timestamped confirmation to the user;
• be able to certify deletion to Strava;
• document and test deletion across primary DB, caches, queues, objects, search indexes, analytics, logs, backups, and replicas;
• never place Strava Data in a persistent index, vector store, knowledge graph, or archive.

Status: ASK STRAVA. The public policy clearly imposes a seven-day cache limit on Strava Data and clearly requires deletion of Personal Data derived from Strava Data after request/revocation. It does not provide a sufficiently clear, BikeTrack-specific answer on whether a maintenance record or extracted route derived from a Strava ride may be retained for the operational purpose while the connection remains active after the seven-day window. Obtain written clarification from Strava before submission. Until then, treat this as a release blocker and do not claim that long-term derived-record retention is approved.

7. Privacy, support, security, and subprocessors

Status: CONFIRMED — STRAVA for a prominent lawful Privacy Policy, accessible support/contact information, deletion/withdrawal instructions and confirmation, subprocessor disclosure on request, security measures, the 24-hour breach notice, and the Terms disclaimer in API Policy section 9.2.

Status: BIKETRACK CONTROL for exposing the following as separate public, unauthenticated pages so the review team can inspect them:

• Privacy Policy;
• Terms of Service;
• Data Deletion instructions;
• Support/contact page.

The Privacy Policy must include data categories, purposes, consent withdrawal, retention, deletion confirmation, providers/transfers, user access, the fact that Strava may monitor and collect API usage data, and the prohibition on AI use.

The individual developer, or an authorized representative accepting the API Agreement for the legal entity, must be at least 18 years old. Keep API registration details current, respond to Strava inquiries, use one API Token for one registered application, and notify [email protected] within 45 days of an acquisition or merger.

Maintain a current subprocessor register containing name, role, data processed, and processing location. Providers handling Strava Data must be contractually bound to protections no weaker than BikeTrack's obligations.

Security baseline:

• least-privilege production access and MFA for operators;
• encryption in transit and at rest;
• managed secret storage and rotation;
• redacted structured logs;
• dependency and vulnerability management;
• tested backup deletion and incident response;
• notification to [email protected] as soon as possible and no later than 24 hours after discovery of a security breach involving the app or Strava Data;
• notification to [email protected] within 24 hours if an API token may have been accessed by an unauthorized person.

Support requests involving identity or deletion must use a private, monitored channel. A public GitHub issue may be offered for non-sensitive bugs but must not be the only path for account, privacy, or deletion requests.

The private support-channel requirement is a BIKETRACK CONTROL based on the risk of publishing identity or deletion-request data. Strava's public wording requires accessible contact information but does not prescribe GitHub, email, or a specific support mechanism.

Do not issue a press release or other public announcement about BikeTrack that references Strava without Strava's prior written consent. Ordinary in-product compatibility attribution must still follow the Brand Guidelines.

8. Brand and UI rules

Status: CONFIRMED — STRAVA for official assets, button dimensions, logo handling, naming, prominence, “View on Strava,” #FC5200, and the allowed interoperability phrases. Synthetic screenshot data is a BIKETRACK CONTROL.

• Use the official, unmodified Connect with Strava asset and link it to the official web or mobile authorization endpoint.
• Official button height is 48 px at 1x or 96 px at 2x.
• Do not redraw, recolor, animate, crop, or change the proportions of Strava logos.
• Never put “Strava” or a Strava mark in the BikeTrack app name, icon, or logo.
• Do not imply sponsorship, endorsement, or official affiliation.
• Strava branding must remain separate from and no more prominent than BikeTrack branding.
• If linking an original data source, the link text must be View on Strava and be legible and identifiable by bold, underline, or the official link color #FC5200.
• If interoperability attribution is used, use only Powered by Strava or Compatible with Strava and use the current official asset.
• If displayed information is derived from Garmin-sourced data obtained through Strava, include Garmin attribution in the form required by Garmin's current brand guidelines.
• Do not invent a brand color from third-party reports. The official downloaded asset and current Brand Guidelines are the source of truth.

Capture every screen that shows Strava Data, the Connect button, Strava branding, or a Strava link. Screenshots must use a synthetic review account and must not contain a real name, precise home location, token, client secret, or private activity.

9. 2026/2027 migration facts

Status: CONFIRMED — STRAVA from the API changelog and authentication documentation.

As of 2026-07-24:

• Club Activities, Club Members, and Club Admins endpoints are scheduled for removal on 2026-09-01.
• Explore Segments becomes restricted to approved Extended Access Tier developers on 2026-09-01.
• The resource API base URL will change from https://www.strava.com/api/v3 to https://api-v3.strava.com.
• The new base URL is announced as available starting 2027-01-04. Do not use the incorrect host www.api-v3.strava.com, and do not migrate production before Strava makes the new host available.
• Strava's official 2026 Developer Program announcement says that, effective 2027-06-01, authorization tokens must be sent in request headers rather than form parameters. BikeTrack already uses Authorization: Bearer for resource requests. Re-test every API call before that date.
• POST https://www.strava.com/oauth/revoke is available now and is the only supported deauthorization endpoint starting 2027-06-01.

Status: CROSS-SOURCE DISCREPANCY / VERIFY LATER. The official Developer Program announcement gives 2027-06-01 as the effective date for header-only authorization and shows www.api-v3.strava.com. The current authentication page already documents Bearer headers, while the current changelog—the official external API change record—uses api-v3.strava.com and announces availability on 2027-01-04. Use the changelog's exact host. As of 2026-07-24, neither current page publishes a retirement deadline for the old resource API host. The 2027-06-01 retirement date is explicitly published for /oauth/deauthorize.

BikeTrack does not currently use Club or Explore Segments endpoints. Re-check this with a repository search before the 2026-09-01 release.

10. BikeTrack readiness snapshot

Status: REPOSITORY-VERIFIED ONLY. This is a code-review snapshot, not proof of Dashboard configuration, deployed behavior, real webhook delivery, retention-job execution, connected-athlete count, or Strava approval.

Present in the repository

• centralized OAuth and server-side credentials;
• requested scopes read,activity:read_all and granted-scope validation;
• encrypted access and refresh tokens;
• recommended /oauth/revoke flow;
• signed webhook validation and a sub-two-second response target;
• persisted webhook event records and idempotent wear keys;
• parsing of overall and read rate-limit headers;
• seven-day cleanup job for activity cache and webhook event rows;
• local cleanup for disconnect, revocation, and activity deletion;
• official 48 px Connect asset;
• public Privacy, Terms, Data Deletion, and Support pages;
• webhook management scripts and synthetic integration tests.

Release blockers before requesting more than 10 athletes

Blocker	Required evidence
No durable retry worker for PENDING/FAILED webhook events is evident; detached post-response processing is not enough for Cloud Run	Queue/worker implementation, retry policy, dead-letter alert, restart/instance-termination test
AI isolation is stated but not enforced while the repository contains a Gemini service	Data-flow diagram, allowlist/typed boundary, automated test proving no Strava-originated field reaches any AI client
Seven-day cleanup does not itself prove deletion of every derived route and maintenance record	Field-level inventory, retention decision, end-to-end deletion assertions for raw and derived records
GitHub Issues is the only published support channel	Private monitored support email/form, response owner, privacy/deletion procedure
Production configuration and webhook delivery have not been proven by source review	Dashboard screenshots, live signed webhook test, 2-second latency evidence, queue metrics
Custom domain stsezhka.com resolves publicly, but production OAuth and webhook callbacks must remain aligned with it	Verify HTTPS, public legal/support pages, OAuth callback configuration, and the live webhook subscription after each domain change
Public documentation is branded “Stsezhka” while the app, legal pages, and proposed API application are “BikeTrack”	One consistent product identity or a clear public explanation of the relationship, reflected in the Dashboard and review screenshots
Ten-athlete demand and real quota usage are not documented	Dashboard evidence of 10 connected athletes and honest capacity/rate-limit metrics

Do not check an item in the review form or repeat a claim in the application description until its evidence exists.

11. Pre-submission release gate

Product and legal

• [ ] Shipped Strava use matches the registered private-maintenance purpose.
• [ ] No cross-user, public, social, competitive, or imitative Strava experience.
• [ ] No Strava Data or derivatives enter AI, agents, analytics, ads, or product improvement pipelines.
• [ ] Users can request access to their collected data and set contact preferences wherever contact data is collected.
• [ ] Privacy, Terms, Data Deletion, and private Support URLs are public and accurate.
• [ ] Product name and ownership are consistent across the app, domain, docs, legal pages, API Dashboard, and review form.
• [ ] Subprocessor register and incident contacts are current.
• [ ] Retention and deletion decisions are documented field by field.

OAuth and security

• [ ] Only read,activity:read_all are requested and granted scopes are checked.
• [ ] State is random, single-use, expiring, and bound to the initiating flow.
• [ ] Tokens are encrypted at rest, rotated on refresh, and absent from logs.
• [ ] Disconnect calls /oauth/revoke, then completes local deletion and displays timestamped confirmation.
• [ ] Secrets are stored in the production secret manager and rotation is tested.

Webhooks and quotas

• [ ] Exactly one production subscription points to the correct HTTPS callback.
• [ ] GET challenge and signed POST verification pass.
• [ ] Valid events receive HTTP 200 in less than two seconds.
• [ ] Durable processing survives process termination and retries failures.
• [ ] Create, update/privacy, delete, and deauthorization cases pass end-to-end.
• [ ] Rate-limit headers drive throttling; 429 does not cause a retry loop.
• [ ] Backfill is resumable and lower priority than privacy/deletion events.

Data lifecycle

• [ ] Seven-day cleanup is scheduled and monitored.
• [ ] Strava deletions are reflected within 48 hours.
• [ ] Disconnect/revocation deletes tokens, athlete/gear IDs, activities, polylines, routes, wear logs, queue payloads, and governed derivatives.
• [ ] Cleanup covers caches, logs, backups, replicas, and indexes.
• [ ] Deletion can be certified and produces written user confirmation.

Brand and review evidence

• [ ] Official Connect button is unmodified and rendered at the approved size.
• [ ] “View on Strava” and attribution, wherever used, follow current guidelines.
• [ ] Garmin attribution is present wherever displayed data requires it.
• [ ] Screenshots cover every Strava-related screen and contain synthetic data.
• [ ] The API Dashboard shows 10 connected athletes before the beyond-10 request.
• [ ] Capacity forecast and rate-limit need are honest and supported by metrics.
• [ ] All public URLs return the expected response without authentication.

12. Rules for coding agents

These rules are normative for every agent working in this repository:

1. MUST read this document before changing Strava code, schemas, UI, legal copy, logging, analytics, AI features, exports, sharing, or deletion.
2. MUST use only synthetic Strava fixtures. Never copy a production response.
3. MUST NOT request, read, paste, summarize, transform, or upload real Strava Data, derived user data, screenshots, logs, or database rows into an agent context.
4. MUST NOT add a Strava field to any AI prompt, context, memory, embedding, RAG, evaluation, analytics, advertising, or cross-user data flow.
5. MUST preserve owner scoping, minimum scopes, token encryption, webhook signature verification, idempotency, retention, and deletion behavior.
6. MUST add or update synthetic tests for OAuth scopes, tenant isolation, webhooks, rate limits, and complete deletion when the affected flow changes.
7. MUST update this document and the submission runbook when official Strava requirements or the implemented data flow changes.
8. MUST STOP and request an owner/legal decision if a feature needs a new scope, a new retention purpose, public/shared display, monetization of API-derived functionality, a new subprocessor, or any AI interaction.

13. Official sources

Claim-to-source map

Claim in this document	Official source
Single Player capacity, self-service capacity/limits, beyond-10 review, demand, no polling for scale	Rate Limits, “Athlete Capacity” and “Adjustment Requests”
Standard 10/9,999, Extended generally 10,000+, subscription variability, no review SLA	API Policy sections 3.3–3.6
Consent disclosure, user access, contact preferences, owner-only display, support, deletion confirmation	API Policy sections 2.1–2.5
Purpose limitation, no competing/imitating app, no API resale/end-user charge	API Policy sections 5.1, 5.2, and 5.8
AI/ML/context/RAG prohibition and no unauthorized agent interface	API Policy sections 5.3 and 5.16
No aggregation/analytics, bulk archive, or persistent index	API Policy sections 5.4 and 5.5
Seven-day cache, 48-hour reflection of deletion, derived-data deletion, 30-day outer limit	API Policy sections 6.2, 6.3, and 7.4
Privacy Policy, subprocessors, breach notice, Terms disclaimer	API Policy sections 7.3, 7.7, 8.3, and 9.2
Age 18+, accurate registration, one token per app, 24-hour unauthorized-token notice, 45-day acquisition notice	API Agreement sections 1.1–1.4 and 11.1
OAuth scopes returned, six-hour access token, refresh rotation, Bearer use, /oauth/revoke date	Authentication
One webhook subscription, event types, two-second 200, asynchronous processing	Webhook Events API
X-Strava-Signature verification and five-minute replay-window example	Webhook signature example (official example; retained as a BikeTrack control)
Official button dimensions, marks, “View on Strava,” and #FC5200	Brand Guidelines
Garmin attribution and prior consent for Strava-referencing announcements	API Policy sections 4.4 and 4.6
September 2026 endpoint changes and January 2027 base-host availability	API changelog
Standard subscription dates and 2027 header-only authorization announcement	Official Developer Program announcement

• API Agreement (effective 2026-06-01)
• API Policy (effective 2026-06-01)
• Getting Started
• Rate Limits and access review
• Authentication and deauthorization
• Webhook Events API
• Webhook signature example
• Brand Guidelines
• API changelog
• API Settings Dashboard
• Developer Program review form
• Official Strava API FAQ
• Official 2026 Developer Program announcement